AltME groups: search

For the defines, I think the best option (and cheapest) would be 
that I prefix the one I use internally for Red.

I guess you'll have to prefix (or suffix) them.

I've been very busy since yesterday on a new tool for Red: I've built 
a proper REBOL code profiler! (I wonder why I haven't done that since 
a long time...). I went through the profiler scripts on rebol.org 
and couldn't one suitable for my needs or that works with complex 
code, so I wrote one. It is able to deal with complex code, all datatypes, 
recursive calls and it's very simple to use.


Here's a demo profiling Red compiler (output is properly aligned 
when monospace font is used):

-= Red Compiler =-
Compiling red/tests/test.red ...

...compilation time:     40 ms

Compiling to native code...

...compilation time:     10189 ms
...linking time:         60 ms
...output file size:     37888 bytes
>> profiler/report/time


Function                       Count      Elapsed Time         % 
of ET

------------------------------------------------------------------------

compile                        1          0:00:10.249          100.0

comp-dialect                   205        0:00:09.659          94.24

fetch-expression               7505       0:00:09.628          93.94

comp-word                      5668       0:00:08.209          80.09

fetch-into                     427        0:00:07.519          73.36

comp-assignment                597        0:00:07.049          68.77

run                            3          0:00:06.492          63.34

comp-context                   21         0:00:06.398          62.42

comp-with                      1          0:00:05.565          54.29

comp-expression                3172       0:00:04.479          43.70

ns-find-with                   24277      0:00:03.962          38.65

finalize                       1          0:00:03.327          32.46

comp-natives                   1          0:00:03.274          31.94

comp-func-body                 180        0:00:03.271          31.91

comp-call                      2775       0:00:02.732          26.65

comp-func-args                 2861       0:00:01.862          18.16

find-aliased                   9650       0:00:01.86           18.14

resolve-type                   8032       0:00:01.799          17.55

get-type                       10758      0:00:01.546          15.08

ns-prefix                      21765      0:00:01.518          14.81

check-enum-symbol              7509       0:00:01.241          12.10

comp-block                     283        0:00:01.05           10.24

comp-variable-assign           417        0:00:01.034          10.08

I wonder for some time why you give long c-like prefix names to every 
functions. 
Is the context not enough? like rebol style does prefer.
Or is that you fear to forget what's doing your own code ? ;-)
Or maybe there is a technical reason behind it I missed.

No offense intedended here Doc, just a genuine question about your 
prefered coding style.

I'm not sure what you mean by "long c-like prefix names to every 
functions."?

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

Pekr: your proposition is not as bad as it could be at first look. 
;-) 


REBOL allows to prefix binary values with a base integer, with base 
16 as default::

    #{F0}
    16#{F0}
    2#{1111111100000000}
    64#{8A==}


We could use a similar convention, but as a suffix, for specifying 
the base for an integer! value:

    123
     7B# 	(default base would be 16 too)
     7B#16
     01111011#2
     173#8


Such literal forms with base explicitly specified would be converted 
to integer! decimal form at LOADing stage. This is just me thinking 
loud, but how does that look like to you?

Lowercase letters are not allowed in hexadecimal literals (both in 
Red and Red/System), so ffffffffh is not a valid syntax. 0x prefix 
is colliding with pair! syntax, so you can't tell if, e.g., 0x13 
is a pair! or an hex literal.

For hex notation in REBOL, I've used (albeit dynamically) a simple 
HEX function with issues. 

  hex #20000001


I'm OK with the suffix approach, but if a prefix approach works I 
like that the prefix clues you in to what you're reading, rather 
than reading the number and then seeing the suffix. The question 
is what sigil to use, if lexical space becomes very tight, as in 
REBOL. Do you have any plans for &?

  &HFFFF000F
  &O77770007  ; though I don't think we need octal
  &B11110001

0%... prefix will clash with percent! datatype literal form.

Anyway, having a prefix rather than a suffix is a possible option.

I haven't found any good prefix to replace # for issue-as-string!, 
so ## is the only option I see so far.

From there, how about \ as a prefix for keywords?

Are there prefix equivalents for the infix operators (+ - etc.) ? 
When I enter + 3 6 in the console, it yields 6.  Why?

I've moved the locations of the Red bindings, dropping the "Red-" 
prefix from #include paths, and normalising the older bindings with 
the latest few that I introduced

as far as i know, zip files allow prefix payload, so you can put 
stuff before the actual .zip file starts... just like REBOL allows 
stuff before the header.   I've seen a demo of a single file which 
is  an .exe,  .pdf ,  and .zip all at the same  time!

16#{} prefix also allowed

When we have group dividers, why are some groups named with a "!" 
prefix ? I find it annoying when manual searching in alphabetical 
order.

ip/prefix prefix stands for the number of bits that are set to one 
in the network. It is a way to partition the address space.

255.255.255.0 corresponds to a 24 prefix in CIDR notation.

postfix operators aren't reasonable to have, the prefix versus infix 
issues are complicated enough

I suspect that originally, the infix operators weren't also able 
to be used prefix.

I think, that it is an *unsafe* and confusing practice to use infix 
operators as prefix

>> cidr-as-mask: func[prefix /local mask][
[        mask: make string! 34

[        repeat i 32 [insert tail mask either prefix >= i [1][0]] 
[        to-tuple load rejoin ["2#{" mask "}"]
[    ]  
>> 
>> same-subnet?: func [src dst mask [tuple! integer!]][
[        if integer! = type? mask [mask: cidr-as-mask mask]
[        (src and mask) = (dst and mask)
[    ]
>> same-subnet? 10.10.10.0 10.10.10.5 255.255.255.0
== true
>> same-subnet? 10.10.10.0 10.10.10.5 24           
== true
>> same-subnet? 10.10.10.0 10.10.9.5 255.255.255.0
== false
>> same-subnet? 10.10.10.0 10.10.9.5 24           
== false

>> prefix: func [filename][copy/part file find/last file "."]
>> prefix file
== %movie.cd1.divx-rel6

but prefix is wrong :-) body uses my global 'file variable - should 
be prefix: func [filename][copy/part filename find/last filename 
"."]

No, that's the element size that causes that. Each block element 
has to hold a 64bit value (of various types) plus some typing overhead. 
Plus I would bet that every block has a one element prefix to store 
the block lengths. Plus, there is the overhead of your reference 
to the block which would be a value in another block.

When I first started in REBOL, I also aliased it as &H (as a func 
name), since that's the hex notation prefix in BASIC and can be used 
as a func name, unlike "0x"

As far as I know, an encloaked string is just a jumbled up, binary 
version of the original string: it carries no prefix signature so 
you can't tell at a glance it is an encloaked string rather than 
another bit of binary.

So, yes, as far as I knoww, you'll have to read and attempt decloaking. 
 Or, if you have control over the writing, ensure some sort of identifiable 
prefix is added)

; I liked this feature of ICON/UNICON where a func can have an initially 
block so I have this in REBOL
initial: func [wd [word!] /list /local functions]
  [
    functions: []
    if list [return functions]
    f: find functions wd
    either (found? f) 
      [return false] 
      [append functions wd return true]
  ]    


initially: func ['wd [lit-word!] blk [block!]][
    if (initial wd) [do blk]
]
; and to test initially
test: func [str [string!] /local prefix [string!]][
    prefix: ""
    initially 'test [prefix: "tested "]
    print [prefix str]
]
; which runs as, say
test "this"
; first time giving "tested this" and thereafter "this"
; thoughts on whether useful enough to go into the org library ?

IIRC, Carl explained (at least) once that this behaviour is different 
on purpose. Using path notation with an index value or PICK should 
return NONE while using the prefix notation FIRST, SECOND,...LAST 
should return an error. So you have the choice to either silently 
handle missing values in series or raise an error!.

unary minus is Negate (in R3). The R2 case certainly is weird:
- why should binary infix operators behave as prefix?
- why should binary infix - operator become unary prefix?

- why should unary prefix - operator have a different precedence 
than any "normal unary operator in Rebol"?

And the reasons to not have a prefix minus:

- It's ambiguous with the infix minus, and we don't have a compiler 
to resolve the ambiguity.

- The special case of DWIM for a missing first argument slows down 
DO, and makes user-defined ops not work.

User-defined operators are planned for R3, but for now you have to 
use one of the existing operators, possibly renamed. If you can switch 
to prefix ordering you are less limited.

These make sense in C or Python syntax, or other languages where 
assignment is a syntax thing, but I'm not sure that it works that 
well with a language with word values, and assignment that doesn't 
use =. I don't see how they'd fit in REBOL syntax. That is not to 
say that the functions that these operators represent wouldn't be 
useful to have - just that they would fit in better in prefix form. 
Just an opinion though.

AND is an op, thus infix, and doesn't have shortcut evaluation. This 
means that you should use AND~ instead of AND if you want prefix, 
but it will still fail if s is a datatype that is not compatible 
with EMPTY? because EMPTY? s will still be called even if SERIES? 
s is false.

The example helps enormously Graham, because you said "first string" 
but now I see you want all matches for a given prefix.

also look at prefix trees, may be a simpiler  variant for word compleation

what is interesting here is, that infix operators are in fact faster 
in REBOL than prefix equivalents ('+ vs. 'add ...)

Geomol, I wouldn't know about R3 but in R2 ops are a little faster 
than their prefix equivalents. The reason is that DO already knows 
which words are ops, while it has to look up other words to figure 
out what they are. This lookup takes more time than just grabbing 
the right action out of the op table. It does have to retrieve the 
index into the op table from the value assigned to the op, but it's 
still faster than general action lookup. Try assigning a non-op value 
to an op word - it will error on evaluation.

Put another way, what is the rule for when a word must explicitly 
bear the sigil prefix of  :  ? I.e., when is a get-word! required 
and when does any word suffice?  ::word is an error but   to file! 
:myString  in a func is no different from  to file! myString   and 
how do you pur carriage-returns into this message-post box!  ;-)

rewrote Peter's with named sub-rules

prefix: [digit opt digit]
sufix: [some digit opt ["-" some digit]]
target: [prefix #"/" sufix]

parse/all inp [any [copy range target (print range) | skip]]

prefix can be:
prefix: [1 2 digit]

digit: charset "0123456789"
alpha: charset [#"a" - #"z" #"A" - #"Z"]

prefix: [1 2 digit]
sufix: [some digit opt ["-" some digit]]
range: [copy range! [prefix #"/" sufix] (prin ["range:" range!])]

rand: [copy rand! [1 4 digit | some alpha] (prin [newline "random:" 
rand!])] 

target: [rand range any [#"," range]]

parse/all inp [some [target | skip]]

is that ok ?

Paul, I don't see how makedoc can do that because one of the goals 
was to having simple tagging where the input source is very readable. 
For these the line prefix (===, ---, ... etc) is that simple tagging. 
To be able to differentiate any value you would have to tag it independently 
and a general template can't know what you want to do.  

If you change the base makedoc to use an external stylesheet instead 
of the embedded styles in the template, you are a long way to getting 
what you want. Combine that with the few special tags you need and 
you can accomplish a lot within the design goals noted.

I mean that you have to have the change keyword physically before 
the rule is affects because all of the PARSE operations are prefix.

Thanks.....that's a limitation of the approach taken by that design 
then.

Probably best not to use the same classes and ids as are being used 
the the templates for data editing. You'd need a list of the "reserved" 
names -- or ask him to use a special prefix to distinguish them from 
the ones you use.

maybe parsing could be done with a prefix-tag. 
 <fill-data><tabel> ... </table>

and the parser figures out where the next tag (the table here) ends.

sounds smart. (forget that prefix-thing, typed before reading about 
id)

At this point just percent and the prefix being dropped from money, 
hence the "almost". No range.

Got that prefix only with source version. Once encapped (with enface), 
I get the proper title.

in C widget libraries the names are quite the same but with a prefix

Can we prefix all files required for a valid distribution of RebGUI 
with regbui-* please? Makes adding it to existing frameworks etc. 
much simpler.

Prefix rg- is OK with me. But remember, people don't know what rg- 
means, and rebgui is only four letters more but hundreds of questions 
less. Never shorten things just to shorten them... semantic is the 
key.

and to avoid clashing (subclassing some levels deep, at every level 
old-engage: :engage) i prefix with area^

Graham, simple fix: Just prefix each field name internally with graham_<field-name-by-user> 
and you are save.

I am having a bug in a program interfacing RebGui to RebDB.

The problem is the following. The behaviour of RebGui'following commands 
having a strange effect on the data managed with RebDB:

my clear-UI function do clears a rebgui interface (simply a set of 
fields) to the RebDB data.

But clearing the 'text fields, it does also clears the values in 
the RebDB database.

At first I was using RebGui clear-text command, and tried the other 
View version just to check.
Both are doing the same thing.

Why clearing the interface fields does clears the data in the database. 
 clear-UI does not ask that.

And no instructions to do that appears in the clear-UI function, 
which is not calling any other function either.

It looks like the 'text field of the fields objects in RebGUI works 
as a direct reference to the database.

And nowhere my code calls by reference. I cannot explain that behaviour, 
nor find any hints in my code as to what causes that behaviour?

Any explanation or ideas on where to look for the cause of that behaviour?


UI-fields: [Funiqueid Fchristen-name Fsurname Fbirth Fname-prefix]
clear-UI: does [
	foreach f UI-fields [
		clear get in (get f) 'text
		show (get F)
	]
	ctx-rebgui/edit/focus (get 'Fchristen-name)
]

Looking at how the rebface object has evolved I note we now have:

	action
	alt-action
	dbl-action
	focus-action
	unfocus-action


and possibly a new keystroke-action. To restore some sanity to this 
(one attribute for each possible type of action), I propose that 
action become a block of the following structure:

	action: make object! [
		on-click:
		on-alt-click:
		on-dbl-click:
		on-focus:
		on-unfocus:
		on-keystroke: none
	]

the on- prefix is deliberate so:


 a) You can read each entry as "action on such-and-such happening"

 b) there is no inadvertent mix-up with underlying functions such 
 as 'unfocus


Note that this change only effects the internal representation of 
actions, it will not change the layout specification (i.e. it will 
not require app script changes).

Comments? Names OK? Any additional actions we need to handle?

Land lines are 8 digits with a 2 digit prefix (e.g. 03 for Victoria). 
1800 numbers are toll-free, 1300 numbers are free for local callers. 
13 numbers are the same but guarenteed to be unique nationwide. The 
later 2 are synonyms for a real underlying physical number, but can 
only be called to from within Australia. Clear as mud ... ;)

node-prototype: context [
    node-name: tag-name: ""
    node-value: ""
    node-type: 0
    child-nodes: []
]

foobar: make node-prototype [
    node-name: tag-name: "foobar"
    node-type: 1
]

bar: make node-prototype [
    node-name: tag-name: "foo:bar"
    prefix: "foo" local-name: "bar"
    node-type: 1
    parent-node: :foo
]

append foobar/child-nodes bar

text: make node-prototype [
    node-name: #text
    node-value: "Some Text"
    parent-node: :bar
]

append bar/child-nodes text

document: context [
    get-elements-by-tag-name: func [tag-name][
        remove-each element copy nodes [
            not equal? tag-name element/tag-name
        ]
    ]
    nodes: reduce [foo bar text]
]

All works, "read/custom url reduce ['POST query-string]" did the 
trick! Thanks guys.

My little 64 line script now does the following:


 1) Read Address Book vCard file and extract a list of number/name 
 pairs (I prefix the numbers with 'n to assist with lookups)

 2) Read each Linksys SPA942 IP Phone's call history and create a 
 sorted list of number/frequency pairs

 3) Join these 2 lists and create a query string for matches and an 
 exception report for numbers without an address book entry
	4) POST merged and updated name/number pairs back to each phone


Script took 2 hours to write and debug, runs in 2-3 seconds and gives 
us the features of an advanced call management facility for free. 
Once again, REBOL to the rescue (my business partner shook his head 
when he saw this and just said, "but HOW can REBOL do all this???").

GNU can continue to develop the term "free" so long as they prefix 
all gnuWords with gnuPrefixes so everyone gnu:knows what one is gnu:talking-about

BTW, The interpreter transform the infix form into a prefix form: 
1 + 1 is really + 1 1

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

LENGTH? is prefix, so to use the infix / you would need parens, which 
have overhead.

I wouldn't use prefix / in a mezzanine - bad form.

in R2 / works as prefix too

I think I've found a good exercice...if only the following is true 
: Rebol seems to handle prefix notation

Operators can be prefix or infix

>> 2 + 3
== 5
>> + 2 3
== 5

You mean prefix.

- cannot be used as binary prefix operator, unlike the others + * 
/

Most operators have prefix only twins (that are called actions). 
Like: equals? is the twin of =

Another question:  How do you setup Rebol code to be performed when 
a button is pressed?

Lets say I want a VID to show a list of websites to open to, and 
I set the default to HULU.
I have the following to setup the correct url:
 k-prefix:	[http://www.]
k-suffix:	[.com]
txt-site:	[hulu]
url-site:	to-url ajoin [k-prefix txt-site k-suffix]

I tried to replace the browse url-site with
browse to-url ajoin [k-prefix txt-site k-suffix]   to no avail.

Is there a way to "predefine" the code above the VIEW so that when 
the button is pressed, it will perform the desired task like

button "Open"    format-and-browse-site    <-- where this has been 
set to do the url-site assignment and browse funtions?

Try this:
REBOL []
; Assignments ------------------------------------
k-prefix:	[http://www.]
k-suffix:	[.com]
txt-site:	[hulu]
url-site:	to-url ajoin [k-prefix txt-site k-suffix]

; Main-procedure ---------------------------------
load-gui
view [
    title "WebSite Selector" 
    text "Please choose a website you would like to open" 
    panel 2 [
        label "URL:" 
        txt-site: field "Hulu"
        label "WebSites:" 
        area 
    ] 
    group [
        button "Open"	browse url-site 
        button "Reset" 	reset 
        button "Cancel"	close 
]	]

Henrik,  I added the following code:

    eval-url-site:	does [to-url ajoin [k-prefix txt-site k-suffix]]
and then after the button "open" i have:
    button "Open"	browse eval-url-site

Also note, that infix operators (like + - * / etc.) are evaluated 
before prefix functions. So

random 4 + 5

is the same as

random (4 + 5)

And operators can also be prefix, which looks kinda weird:

>> + 4 5
== 9
>> random + 4 5
== 2

Mail can be good for ad hoc databases, but in my experience, keeping 
track of a conversation can be a bit of a nightmare if you are not 
careful, changing the subject line or something that will screw the 
thread up. This depends on how good the mail client is at threading. 
There is also a problem with certain mail clients not adhering to 
the Re: standard reply prefix for subjects.

Seeing how different people use mail clients very differently, it's 
hard to keep posts flowing in a readable way, if they continously 
decide that every mail needs a new subject, or the subject line is 
blank. This happens for people who are not accustomed to posting 
on mailing lists, where structure is very important. Unfortunately 
most customers that I deal with, do not use their mail clients efficiently, 
because they are unaware of the weaknesses of email. Email was designed 
in an era where sending text messages across phonelines were considered 
pretty high tech and was mostly used by technical people and only 
in select locations.


Just today I was looking for a mail inside an old thread, a response 
to a question I had asked a customer. I couldn't find it. It turned 
out that the customer apparently had never answered it, but I can't 
be sure whether I had accidentally deleted it or if the mail client 
had stowed it somewhere else. Mail just doesn't cut it anymore. It 
needs to be replaced with something much more rigid and with structure 
forced upon it by the clients. Significant protection from spam should 
be there by design, not by throwing advanced algorithms, money and 
CPU power at the problem.


This is why I like AltME. You have the instant messaging capability 
and I can still write long blurps like this one without loosing structure 
of an ongoing one-line conversations in the same thread (group in 
AltME). It'll end up in the right place. It's going to be very certain 
that you'll be able to read it a few seconds after I hit Send. It's 
logged and searchable, though it will scroll out of view quickly.

1) how to influence where it stores/creates database?


Don't know, I've only been looking at all this for a day and havn't 
worked that out yet either.


2) if I would use separate file for some tables, if it would be able 
to join them


Yes. The ATTACH command lets you "hook up" to multiple databases, 
and you can prefix references with database name.

3) noticed there is brand new version of techfell protocol


Of the *four* sqlite scripts on REBOL.org %sqlite3-protocol.r is 
the one to use if you have a Pro licence.

4) those guys are really screwing with GPL license ...

Who? SQLite is PD as is %sqlite3-protocol.r

As I mentioned near the beginning of this thread, SQLite supports 
multiple database files each containing one or more tables - in fact 
they go so far as recommending that you separate multiple high-access 
tables out into different databases for concurrency reasons. In this 
sense, SQLite "databases" act more like traditional "tablespaces". 
So, if we wanted we could write our REBOL front-end so that it created/accessed 
each table in a database of the same name thus ensuring a one-to-one 
mapping between table names and database names. The advantages of 
this approach are:

	backups (only those tables that change need be backed up)

 external table administration (you can drop a table by deleting its 
 database file)

 concurrency (you spread your file locking across a greater number 
 of physical files)

Disadvantages:


 Administering your database is more cumbersome (you can't use the 
 sqlite3 admin tool to administer all tables in one session)

 Value of sqlite_master is diminished (you can't "select * from sqlite_master" 
 to report on all your tables in one query)

 Query references need to add a database prefix when referring to 
 a table not in their own database

 Name conflicts (all tables in one file means multiple databases can 
 use the same table names - the solution with multiple files would 
 be to segregate at the directory level)

 Multiple database files means you need to zip them prior to some 
 operations such as email attachment, etc


On balance, I actually prefer the one file / one database approach.


Pekr's other comments in relation to schema implementation also have 
merit (I've agreed with Pekr twice today - a new record!); I see 
the value of an ftp schema, an http schema, etc; but what value in 
a sqlite schema? Given that the entire schema can be written in a 
much more concise fashion as an anonymous context that exports a 
couple of key access functions to the global context; I can't see 
what the functional differences between the two implementations would 
be?


So, bar any good reasons to the contrary, these are the features 
of the implementation I am currently working on (a rough design spec 
if you like):

	Implemented as an anonymous context

 "Database" is a directory (which is specified when a database is 
 opened with 'open-db)

 Each table resides in a "tablespace" (aka SQLite database file) of 
 the same name
	File is automatically opened on first reference

 The /blocked refinement of 'db-open specifies that rows will be returned 
 in their own block (default is a single block of values)

 Non-numeric values (which SQLite stores natively as INTEGER and REAL) 
 will be subject to 'mold/all on insert and 'load on retrieval

 The /native refinement of 'open-db will turn this behaviour off (see 
 comments below)

 SQLite binding will be supported allowing statements such as ["insert 
 into table values (?,?,?)" 1 [bob-:-mail-:-com] "Some text"] and ["select 
 * from table where email = ?" [bob-:-mail-:-com]]


Whether to store values (including string!) as molded values in SQLite 
is an interesting question; on the one hand it gives you transparent 
storage and access to REBOL values – but at the performance cost 
of having to mold and load every TEXT value returned; and the storage 
cost of the overhead of a molded representation. On the other hand, 
if I only want to store numbers and strings anyway then I don't want 
this overhead. I think the only practical solution is a /native type 
option as detailed above.

Ashley - maybe I vote for functions having sql- or sqlite- prefix 
.... sql then could become sql-query .... because ... standalone 
"disconnect" in rebol script is a bit strangely looking .... in rebol 
you can disconnect from many things ... it does not look obvisous 
at first sight .... what do others think?

also open, close vs connect, disconnect ... evne rebdb has db-open 
.... looks good ... maybe db- would be nice, telling and short prefix 
...

I also don't agree with exposing functions as you did it, without 
prefix of sqlite or db .... that aproach is flat ... and unless it 
is not forbidden by sqlite itself, I don't see a reason to limit 
ourselves to have just one openened database .... I will shortly 
try it ...

ad 1) I was referring to the context of foreign script reader understanding 
- you used db-open even for rebDB - as I said, it is a detail, but 
makes sometimes things more clearer ...


ad 2) I was imagining simply kind of server product, which can open 
multiple unrelated databases ....


ad 3) kind of disadvantage here to not refer by pointer. We are used 
to it, no? Look at /Command or other schemes - db: open some-db://..... 
conn1: first db conn2: first db ... db2: open some-db://..../other-db

ad 4) OK


ad 5) db- or sqlite- prefix or let it the way it is, I will assign 
it to sqlite: context [] directly in %sqlite.r

you used db-open even for RebDB

 ... that's because it needed to define about 20 low-level SQL statement 
 functions like 'select, 'delete, ''show, 'close, 'insert, etc that 
 conflicted with existing REBOL words and could not be easily renamed 
 (folks expect a SELECT statement, an UPDATE statement, etc or something 
 that resembles it). With the SQLite driver, all these statements 
 are handled by the SQLite library itself so we only need to provide 
 a few high-level accessor functions like SQL and DESCRIBE; these 
 types of words don't conflict with REBOL's lower-level atomic action 
 type words so there isn't the same need to group and isolate them 
 by prefix and/or context.


kind of disadvantage here to not refer by pointer. We are used to 
it, no?

 But is it *needed*? If you *must* work with multiple databases concurrently 
 and *cannot* have them attached, then SQLite is probably not the 
 right solution for you anyway ... it's an embedded C library with 
 limited concurrency and no user rights management after all. ;)

what? equal? is a prefix version of the = op

I've always found AND and OR not very rebolish, maybe because they 
can be infix (operators), where ALL and ANY are prefix (like functions). 
And you often need parenthesis, when used infix:

>> or 1 = 2 2 * 2 = 4
== true
>> 1 = 2 or 2 * 2 = 4
** Script Error: Expected one of: logic! - not: integer!
** Where: halt-view
** Near: 1 = 2 or 2
>> 1 = 2 or (2 * 2 = 4)
== true

slim also has an auto-prefix option when you import words.  so as 
to make "collections" easy to differentiate, without having to rename 
each one separately.

As for bug #576 - I don't care if the currency prefix will not be 
there anymore... or do you really need it? You cannot do USD$1 + 
EUR$1 anyway.

steeve, this isn't a noun prefix.

Janko, I agree on one point, i dislike the name remove-each (too 
long).

Why don't we use the short name "filter" which is not used anywhere 
else (so we don't need -each prefix to decipher it from other uses).

More complex
 = "like R2". He was asking about restoring the unit prefix.

You wouldn't be able to make a unit a number!, or even a scalar!, 
but otherwise doable. As long as the unit is on the left side of 
a equation it would work. You wouldn't be able to replace money (prefix 
vs. postfix), but otherwise good.

It still wouldn't replace money!, because the international standard 
syntax for specifying money uses a prefix, not a suffix.

I also vote for the module system to support the ability to restrict 
what you import, and SLiM's ability to rename words on import (and 
prefix them) is very nice.

Some tweaks:
- OR~, not ~OR

- AND~, OR~ and XOR~ work in R2 as well, and should be used instead 
of AND, OR and XOR for prefix use.

The only problem that I have with + is  that it's *not* an infix 
operator, it's prefix.

EITHER doesn't work like EITHER, and it needs to be prefix, and use 
the semantics of Carl's + proposal or it won't work. Suggest a name 
to be used instead.