World: r3wp

that's good!

I won't waste my time then :-)

i don't know if we're going to have your suggested loop or pad refiniments

but, note that it is very likely that foreach will be a mezz, so 
we you can improve on it :)

pad and loop are sort of gimmicks anyway. I think the multiple block 
part is the important thing.

funny, i thought i was the only one wanting multiple blocks.

I really miss it alot

such a construct would make certain loops much simpler

When you combine this with the word, set-word trick, this could make 
for some interesting structure matching.

ah, about structure matching... let me switch to another group

Sure, as long as it's fast, make it a mezz and let it evolve.

Someone mentioned Ladislav's build dialect, and look what happened 
to it... ;-)

 - it was me who mentioned it, but this is about the third time I 
 mentioned it here as well as on the ML, so it is not as efficient 
 as Brian suggests :-)

I posted a comment to hash that contains the reason why Carl is reconsidering 
the HASH! datatype

re the BUILD issue - it has been used quite regularly, although not 
for lit-paths, because they are "rare" in a sense

Well I was joking, but yeah, the community-as-optimization does depend 
on the community having time and attention to spare...

Brian, you mentioned the usage of HASH! as an index. That is exactly 
the case (IMO) when HASH! is better than associative array. Are you 
using that often?

Sometimes I return a hash index as a query result set, for database-like 
functions. If I had to use an assoc instead I'm sure it would be 
fine as long as select was still O(1) like a hash.

Most of the time I use it like an assoc, or like a fully indexed 
table.

The main advantage a hash has over an assoc is that you aren't limited 
to simple key-value records, you can use longer records.

I would want an assoc to be able to have any string type as a key 
and words as well, at least.

The main advantage a hash has over an assoc is that you aren't limited 
to simple key-value records, you can use longer records.
 - yes, that is the domain where hash! should be better

(especially if you want to use more keys than one)

Plus you can use more interesting dialected records that are type-delimited 
rather than fixed length - all the tricks that blocks can do.

Still, if assocs are drastically faster it would be worth it. I could 
use blocks or lists and assoc indexes if I need them.

Assoc indexes to lists would be useful, as useful as I've found hash 
indexes to lists to be. I'd use hashes and lists more often if block 
parsing worked on them.

drastically faster

 - I think, that REMOVE and INSERT can be made faster by not "shuffling" 
 data as often

...as useful as I've found hash indexes to lists to be
 - do you have a short sample code you can post?

Insert tail
 should be not slow?

for remove, dont use it, clear the values instead. and have some 
way to recycle them.

Mostly adhoc database stuff that could be replaced by RebDB. I really 
can't post most of it (work for hire).

I've been wanting to look at the source of RebDB to see if there 
is anything about it I could improve.

right, Volker, that may be the way but if you need such tricks to 
just obtain the functionality you want, don't you think it may be 
better to get the necessary functionality natively?

I guess RebDB doesn't use indexes as much now, but I'm sure there 
are some ways it could be helped.

I also would like to see an example fo "hash indexes to lists". So 
far I have not yet see a situation where this is better than just 
a single key value mapping.

it is clear that if you want to use at least two different keys to 
access the values, then it is better to use hash!

if i loose the block-functionality i even prefer such hacks. and 
i never needed that remove-tuning, only figured it out for some benchmark. 
Where it paid of only with large data. And with large data, maybe 
i want the hash on disk anyway?

related: will we get a native 'append ? If such speed-isues are now 
important, we should notstick with that important thing as meazzine?

 at least two different keys to access the values, then it is better 
 to use hash!
 Well how is that different than an Associative Array or Map?

Jamie, that was referring to using a hash as a table rather than 
as an index. If you use a hash rather than a block for your table, 
all of your searches would be faster without needing any seperate 
indexes. The only way to have the speed of searching a block be comparable 
would be to keep it sorted and use a binary search (what RebDB does 
I think), but that doesn't help much with multiple keys that require 
different sorting orders.


On the other hand, I've been sold on the idea that when you use a 
hash as an index (rather than the table), you are basically using 
it like an assoc, so using a structure optimized for that behavior 
would probably be best.

As for the hash (or assoc) index and list data combo, it has some 
advantages. When you are inserting and removing data a lot lists 
have a known speed benefit but the real advantage as far as indexes 
are concerned is in how lists handle series offsets (I'm using the 
word offset here because I'm using the word index to refer to the 
external hash/assoc index).


Blocks encode their offsets as a number offset from the beginning 
of the series:

>> a: [a b c]
== [a b c]
>> b: skip a 2
== [c]
>> index? b
== 3
>> insert next a 'd
== [b c]
>> b
== [b c]
>> index? b
== 3

List offsets are pointers to the associated list element.

>> a: make list! [a b c]
== make list! [a b c]
>> b: skip a 2
== make list! [c]
>> index? b
== 3
>> insert next a 'd
== make list! [b c]
>> b
== make list! [c]
>> index? b
== 4


If you are indexing your data and your data in in a block, you need 
to update your index with almost every insertion and removal because 
the references to latter positions of the block in the index will 
be invalid. With list insertion and removal, external references 
are likely to still be valid unless the referenced elements themselves 
are deleted. If you are sure to delete the reference from the index 
(or replace it with nones) the rest of the index should be OK. New 
index references can just be tacked on the end, or put into the first 
empty entry. This makes live indexes a lot more practical.


On the down side, if you are using lists and they are long enough 
to make linear searches impractical, you really do need an external 
index for them to be useful. Also you need to balance the overhead 
and complexity of keeping the indexes updated against their benefit. 
This technique is not for the faint of heart unless you can get some 
guru to do algorithms for you.

I am confused by some terms in REBOL 3. Can I say:

* A component is a plug-in.
* A plug-in is a component.
* A component consists of at least one module.

You might want to wait for some more information about modules to 
be revealed before asking that question yet. As it is now, components 
are compile-time features of REBOL 2 that can be included or excluded, 
enabled or disabled, in one chunk when building a version of REBOL. 
Only RT and SDK licensees have any control over that.


Plugins and modules are features of REBOL 3 that haven't been documented 
yet (maybe not finalized either). It is unknown whether REBOL 3 will 
even have components at all, or whether they will be replaced by 
modules or plugins.

Try a search on Carl's blog (not R3 blog) with the word : "module 
". You will see a dozen of answers. See http://www.rebol.net/docs/modules.html, 
also. A first step to learn about modules.

But don't forget that those references are to an older proposal for 
modules that was based on a different set of internals than REBOL 
3. If even the syntax for modules is similar to that listed in the 
old proposals, it would be surprising. It is almost certain that 
the semantics will be different, as the underling REBOL semantics 
are certainly going to be different.

underling -> underlying

A design question: "If we allow a function-local return, is it ever 
the case that we have a recursive usage of the function that  may 
request a return from different instances of the recursion?"

any thoughts?

I think we don't need such a feature

You're always at least three steps ahead of me, but my head hurts 
just thinking about it (a return from different instances of the 
recursion). :-)  


What about generators, like in Icon, that step through alternatives? 
I've never used Icon for real, just tinkered a bit, and that powerful 
feature seems to lead away from readability. I also don't have an 
example of how it might be done in REBOL, or if it applies to your 
question. 

I'm a big help, aren't I? :-)

What means function-local return ?