World: r3wp

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 ?

example:

f: func [

    /local g return-from-f  ; any local word can do the same service
] [
    g: func [n] [
        if n = 0 [
            return 0 ; "classic" return, nothing special
        ]
        if n = 1 [

            return/from 1 'return-from-f ; this causes F to return the value
        ]
    ]
    g 0
    g 1
    g 0
]
f ; == 1

That is basically doable with throw/catch, but semantic sugar?

I would state it the other way around - Throw/Catch are doable using 
functions with local return

the opposite is not true

on OSX, it would be nice to have native access to file metadata (what 
"mdls filename" return from the terminal in Tiger) with something 
like info?/all or info?/meta or info?/metadata returning an object 
with the metadata.

Ladislav, yes, I don't think we need the feature :)

Ladislav, I don't have time to think it all to the end, but an advise: 
Keep it simple!


I know, it's a very hard goal to reach, because we don't want to 
cut off possibilities. If it's possible for someone new to the language 
to use a feature like "function-local return" right away with expected 
result, and still the advanced programmer can use the feature in 
a way maybe not obvious at first, but that makes good sense, then 
it might be perfect.


But don't make the advanced programmer happy, if it'll make things 
difficult for the newbie.


recursive usage of the function that may request a return from different 
instances of the recursion

 sounds complicated at first. I think, you're right. We probably don't 
 need such a feature. If the code (C source) become simpler by including 
 the feature in recursion, then you might consider it though.

it seems to be the other way around - adding this feature may complicate 
and slow down the interpreter as it looks. Otherwise my observations 
are, that Carl is taking care to keep REBOL simple. (beginners don't 
need to use functions with local return at all)

hmm, mid May, I wonder if some eeeeearly alpha 3.0 Core is already 
starting to emerge on Carl's harddrive :-)

Ladislav, then it's easy. Leave the feature out, as you suggested! 
:-)

petr, sure it's running on Carl's computer. it has probably been 
for a while. it'll be more interesting when it starts working outside 
of his computer too ;)

gabriele, looking forward to the behind-the-scenes DVD! :-)

lol, we should ask carl to keep a video camera in is studio maybe 
;)

that would be good. 4 hours of video, watching Carl typing on his 
keyboard.

Someone send Carl a webcam, please! ;-)

Oh, he already has a webcam!!! Here's a snapshot from it: http://www.bronzelady.com/ARMANI/fantasia.jpg

if those were the methods of development, I would not have any trust 
in a REBOL3 release :-)

then again, Arthur C. Clarke said "Any sufficiently advanced technology 
is indisinguishable from magic." What if wizards like Gandalf or 
witches really are people from a distant future? :-)

hehe You make me think of the sci-fi novel "Hyperion" by Dan Simmons. 
In that nano-technology has advanced, so you can have little invisible 
robots in the air around you doing "magical" stuff. Read it, if you 
haven't! One of the best. Same idea in the online role-playing game 
"Anarchy Online". Lots of fun!

Michael Crichton reused the idea in "Prey"

In that novel, the nano-bots couid only be destroyed in the final 
chapter by a bunch of peasants with flaming torches.

Hang on, no: it was a bunch of techies with thermic lances. But they 
didn't use REBOL to program the little critters.

Ladislav, Doesn't RETURN/FROM promotes 



spaghetti coding ?

;What do i miss?
f: func [
    /local g
] [
    catch/name [
        g: func [n] [
            if n = 0 [
                return 0
            ] 
            if n = 1 [
                throw/name 1 'return-from-f
            ]
        ] 
        g 0 
        g 1 
        g 0
    ] 'return-from-f
] 
probe f

Jaime: spaghetti coding always possible, this is to enable control 
functions which need such features

Volker: I probably didn't say it clear. Your are right, that  the 
example can be implemented using Catch/Throw. What I wanted to say 
is something else:

Throw/Catch can be implemented using local return functions. Local 
return functions cannot be implemented using Catch/Throw.

Hmm, spaghetti coding: when I think about it, this is a step in that 
direction, yes.

Regarding the example Volker wrote: yes, it is a way how to do similar 
things, but it differs - Catch/Throw ignore contexts, so the behaviour 
is not equivalent, although it looks so

Contexts are a good point. Spagetti: oi agree. Hard to see there 
is a hidden return when looking in 'f. But maybe 'catch could use 
contexts, or would that be overkill? Or, catch, explicit 'equal? 
and rethrow otherwise? (or was it 'same? have to look on the ML ;)

Ladislav: could you give an example of a controlfunction where it 
would be useful ? Now I know what it means, but don't have an example 
in mind, when/how I would use it. Nevertheless, I'm always for having 
concepts in the language which make things possible, which otherwise 
would be hard to achieve (or just by doing some tricks with other 
language constructs - note! doesn't necessarily mean the catch example 
- can't judge this). If a normal user won't be affected and it's 
ok with Carl and the implementation - why not having it?

Guessing: in recursion one typically goes into a function, guess 
a few ifs deep, does some work and returns. 
 either n > 0 [do-work exit][recurse n - 1]

If that is long, one ants to split that in multiple functions, indirect 
recursion
  f: func[n][  some-checks-or-return  g-checks n]
  g: func[n][either n > 0 [do-work exit/from f][f n - 1]
And that is not possible, one can only exit 'g itself.

guess -> goes

ants -> wants

coffee -> mouth .. (urgent!) *sigh*