World: r3wp

For that matter, I thought the point to runing a block of code with 
a loop 1 was to catch breaks. Can you rebreak?

while: native [
    {While a condition block is TRUE, evaluates another block.}
    cond-block [block!]
    body-block [block!]
    /throw {pass along break}
]

Do you mean you could write:
	while/throw user-cond-blk user-code

No, I think Ladislav just used loop 1 as an example of any of the 
looping control structs.

Sounds good to me Ladislav. Add it to the other loop functions too.

For that matter, I thought the point to runing a block of code with 
a loop 1 was to catch breaks.
 - sorry for my oversimplification, I didn't mean to use *only* 1

Sorry for the misspellings in that comment too :)

Add it to the other loop functions too.

 - this is a "higher level" business and I will be content with having 
 at least WHILE/THROW. I guess, that it will not be used frequently 
 (?)

Moreover, it looks to me, that we are able to "simulate" such a construct 
using PARSE in REBOL2

If you add /throw to while, it should at least be added to the other 
native looping functions. I will be used if it is there, and being 
consistent is easier than explaining the lack of consistency over 
and over again.

OK, I will ty to convince Carl to add it to REBOL 3

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 :)