World: r3wp

Of course FOREACH of map! would operate in the order that TO-BLOCK 
map! would return the keys and values at that moment. In the long 
run you would have to consider the order of FOREACH map! to be non-deterministic 
between calls. The map! type has no inherent ordering, so position 
and sorting are meaningless for it.

hashed doesn't mean ordered?

It doesn't. SELECT works on object! and map!, but there is no comparison 
except equality for those types.

Hashed means indexed (in the database sense), not ordered.

my fault I missmatch rebol select with SQL like select

IE if you expect quite large number of keys would you have any chance 
to "narrow" like "sql between"

Map! is not indexed in the REBOL sense, ironically enough: no position.

OK now I have more clue, all this is toward key/value datastore preferably 
diskbased something I believe Paul is trying in R3

REBOL is a lower-level language than SQL. No set operations (for 
map!, ar least). Those kinds of SQL operations need to be done procedurally 
in REBOL, using block copies and such.

We will have REBOL Indexed Files (RIF) for the disk-based datastore.

I'm really currious believe me, like small boy

Well, we don't havee RIF yet so you'll have to stay curious for a 
while :(

I'm keeping finger crossed not to be too old to be able enjoy truly

But seriously thanks for all the job is done until now

hmmmm.... interesting behaviour of blocks....

Brian, does that mean that Carl had in main a possibly new feature 
asked for a while: 

RANGE :A reference which is a sub part of an existing serie. (supress 
the need of overheaded copy/part in our sripts)

I think it's not at all tricky to implement if the head of a serie 
is a logical offset now.

(had in mind)

Must be RIF native or is it possible to mimic in rebol as is now

is it question of mold load on each read?

No, there are no plans to implement range. The head and tail of the 
series are attributes of the series, not the reference to the series. 
It's like the difference between the position attribute of a port 
and a series: For a series, the position is an attribute of the reference 
to the series, while for port, the position is an internal attribute. 
Still, a subseries reference could be implemented as a user-defined 
datatype as long as it is careful to make up for changes in the underlying 
series.

I think that the idea was to be able store internal REBOL values. 
I mean that you for example close console with some defined values 
and after restart of the console you could load into the state where 
you ended.

At least I think Carl was somewhere talking about that. And that 
it could for example speed the boot time, which could be useful for 
cgi aps.

Correct me, if I'm wrong:)

I am really curious to see how binding issues are resolved with RIF. 
You could just have the data come out of the RIF unbound...

Oldes, you are not wrong here.

just to say the virtual-block scheme is an exemple of how RIF could 
be implemented (see http://sites.google.com/site/rebolish/for the 
source)

Although Carl was actually talking about rebin to speed up the boot 
times, not RIF :)

RIF files were going to be binary (rebin), not source like Steeve's 
virtual blocks.

Oldes - was it RIF? Wasn't it Rebin?

Maybe it was rebin... all these far future projects:)

Brian, i added the option to save the data as row binaries today 
in VBS

all other values are stored as molded values

I saw that. Does it save all REBOL values in binary, or just binary!?

except binaries

just binary!

Still cool :)

binaries are saved as-is (compact format), all other values are molded 
before being stored as binaries

Rebin is intended to be a binary syntax for REBOL, like EBML for 
XML. All REBOL values (or maybe just the literal values) will be 
stored in a binary format. I suppose rebin would be an output format 
of MOLD and SAVE.

You would need something like RIF to restore the bindings though, 
since you could translate references to RIF indexes. In theory.

You would need a binary format to even have a way to store those 
references since REBOL syntax doesn't, even with MOLD/all.

hmmm... the rebin format will be hudge, cause for series, there is 
2 indirections (2 references) + the value himself

am i wrong ?

No, just the value and the reference to the value with the position. 
The poisition isn't a reference, just an integer (internally). So 
you need the series, the length of the series, a datatype tag, the 
reference to the series, and the offset. The reference and offset 
would be part of the contents of anotther series. It would take less 
space in binary than in memory or REBOL syntax.

I'm not sure that you're wrong though. There's also the index to 
consider.

ahah.... i was near to argue you...:-)

Brian you must be looking over the Carl shoulder :)

The only thing I could dispute would be the "huge" part. References 
wouldn't necessarily need to be stored as full 64-bit integers if 
there is an index, so there could be even more space savings, though 
speed would be king for RIF I expect. In any case I expect much more 
space savings than REBOL text syntax.

As for looking over Carl''s shoulder, I've been more following the 
process and discussions. If you know the REBOL semantics and have 
experience implementing this kind of thing yourself, the big picture 
is obvious. Carl's better at this than I am though - I can only guess 
so far.

B: next A: "blabla"

A (contains a logical reference) --> (physical reference)-->"blabla" 
(value)

B (contains a second logical reference to the same physical reference) 
--> 

if "blabla" is expanded the physical reference is modified and "blabla***" 
is stored in another one place.
The references in A and B are not modified.
That why i said there is 2 indirections (2 references)

but perhaps i use wrong words to explain

I was only disputing "huge", not the rest.