World: r3wp

The only thing I would be wary of is that every low-level refinement 
you add is one more either statement if you want to pass the refinement 
along from the mezannines. Has Carl figured out how to deal with 
that structural problem in the REBOL language?

just a side note: it looks, that we will get CONTINUE in REBOL 3 
too and I suppose the /THROW to "pass along" CONTINUE too

regarding the structural problem: we should convince Carl to give 
us a comfortable APPLY function, shouldn't we?

That is my favorite part of rebcode, by far.

:-)

so, I guess that it would be nice if you found a spec for APPLY that 
would be able to handle refinements in some way

The APPLY in rebcode handles refinements just fine.

(need to check that, didn't use rebcode for quite some time)

I used it quite a bit. You remember how much I posted in the rebcode 
group :)

yes

actually I wrote Rebcode test suite but am not sure how thoroughly 
I tested APPLY

I hope rebcode is integral part of R3, although some guys were concerned 
about security (not being able to crash rebol by faulty rebcode code)

APPLY would take refinements as positional arguments. That meant 
you would need to match the order of refinements in the declaration 
of the function you are calling, and that your function call would 
break if the function changed the order of its arguments - fragile. 
For some reason APPLY was slow too, and would crash REBOL if run 
too many times in a rebcode function.

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.