World: r3wp

ah, really? can you supply code for that?

function call would break if the function changed the order of its 
arguments - fragile
 I am afraid, that it is hard to find a less fragile spec, though

Look back on the rebcode group. It was a standing problem. I was 
more concerned about it being slow as dirt though - the instability 
was likely to get fixed, but the slowness may be structural.

Can you get from a refinement to the word it is based on? Are refinements 
bound?

If so, you could pass along the refinements as keyword arguments 
in a REBOL version of APPLY.

Are refinements bound?
 - refinements are not bound usually

Oh well, there goes one idea for a less fragile interface.

...but if you write f: func [/a] [/a 'a], then the /a refinement 
isn't bound, but the 'a *is*

But if you write
    a: none
    apply :f [/a]

then the apply function can't tell that it should be passing the 
/a refinement as none.

If /a is not bound, I mean.

right, you would need to write apply :f [/a a]

(or something similar)

Not bad really, but slower than positional arguments I suppose.

highly probable

Regarding R3 tasks...

Will any thread be able to kill the main process?   or are we stuck 
like with python?

hmm, that depends on a lot of things. i'd say yes, but otoh there 
may be cases where that is not a good idea. it's to early to say 
anything about that, anyway.

Gab, do you know if R3 threads are soft or native threads ?

native, at least that was the idea.

personally i somewhat prefer soft, but native has the advantage of 
making use of multiprocessor machines.

I agree... and with dual cores becoming increasingly main stream... 
there is a definite advantage in that.

i don't know if it will be easy to use native threads across all 
platforms though.

hehe if windows didnt design "kill a task" from inception... I can 
only imagine how well its threads must be implemented.  <sigh>

although they require very little RAM IIRC

unix is probably not that great on threads either, i think everyone 
is using their own variant.

there is a crossplatform library iirc, i hope it works :)

Threads are actually done very well on Windows. They also have a 
fast shared-memory thread-like thing called fibers. It was only recently 
that some of the Unixes were able to catch up (except Solaris, which 
may be better).

Windows sucks at processes though.

(BTW, I meant that Solaris may have been better than Windows at threads 
already. Stupid English.)

Please refrain from calling we English stupid ;-)

Just teasing

brian, my fear is having differences across platform. the complexity 
can go up very easily, especially when there are platforms that support 
threads badly.

i hope that, as you say, most unixes have catched up at this point...

then Carl should look for very small kernel to license, which solves 
that - e.g. QNX - it has 75KB kernel IIRC :-)

I really wonder, what R3 will be about - tasks (threads), new event 
system ... when thinking in cross-platform terms ...

Linux and all of the commercial Unixes are good at threads now. I'm 
not familiar with the BSDs.

OpenBSD and FreeBSD have very good support for them. NetBSD is lagging 
behind. DragonFlyBSD has even better threading model.

http://www.plausible.org/nasal/

http://wiki.flightgear.org/flightgear_wiki/index.php?title=Nasal_scripting_language
Nasal - small, os-threads, used in flightgear.

Maybe the treading is usefull?

anybody able to find good  names for zero-based index series functions 
like variants of PICK, POKE, etc...?

(any other any zero-based indexing suggestions welcome)

peekus and pokus - more like ancient Latin language roots...

pokus
 means "trial" in Czech

zpeek, zpoke ?

Didn't we have this kind of discussion with rebcode ?

cee caw

what's the logic behind that, Tom ?

four days of fever and chills
that and c - zero based arrays

(the latest names are PICKZ and POKEZ, but I am not sure they are 
acceptable)

I'm not sure we can do better, Ladislav.