World: r3wp

But the current way does too..

except for control-structs, as it is now. and that should break the 
control-struct, so not lexically.

 - actually, in case of control-structs what you really want is lexical 
 break as you pointed out above and as can be demonstrated by:


    control-struct-test: func [control-struct [any-function!] code [block!]] 
    [loop 1 [control-struct code 2]]

>> control-struct-test :do [break/return 1]
== 1

I think lexically. if i pass a closure with a break, it should at 
least break into my code, and not inside some foreign code where 
it creates havoc.

we typed the same conclusion at the same time :)

yes

I am happy with break breaking functions.

I like the dynamic way, but maybe there is some compiler-optimization 
possible when doing it the lexical way ?

1 = loop 1 [
			f: does [break/return 1]
			f
			2
		]

But we need a way to enforce cleanup? something like 'finally? If 
a module provides an
  open-do-close [my-code]
my code should not be able to avoid the close?

(independend of the scroping-question, the current way is broken 
too)

regarding optimization: for the interpreter the dynamic way is faster, 
but it leads to "unexpected effects" sometimes as I and Volker agreed

What is wrong with the control-struct-test example ?

Nothing, it just demonstrates, that we may lexically expect 1 to 
be the result, but what if somebody did:

    my-control-struct: func [code] [loop 1 code]
>> control-struct-test :my-control-struct [break/return 1]
== 2

so in REBOL2 we cannot (at least not in a simple way) use loop when 
implementing a control struct

Seems to me to be just one of the side-effects of dynamic code.

I see the problem, but I am just cautious of making just one part 
of rebol non-dynamic.

So, you aren't specifying that your function f should pass along 
breaks, and you want it to pass along breaks? Even lexically the 
break is inside the f function, not the outer function. I don't get 
it, Ladislav.

Brian: the problem is not with the function, the problem is with 
loops - the loop should either pass along break or not

Sorry, I get it now. I was mixing up break and return.

the code is complicated, sorry ;-)

I would normally be on the side of dynamic break - it would be easier 
to teach, and the rest of REBOL follows that model. What would be 
the major advantage of lexical break in a non-compiled language? 
REBOL code blocks aren't really lexically associated with their control 
structures in the DO dialect, as my conjoin and delimit functions 
above demonstrate. This isn't rebcode you know.

right. OK, in case we will use dynamic BREAK in REBOL3 (highly probable), 
I will propose to introduce a new /THROW refinement for the WHILE 
cycle to "pass along" BREAK and that is all

What's the problem with using the real throw function here?

the real throw function does not pass along BREAK

(I just want to have one cycle function able to pass along BREAK 
when needed)

Can you use the same solution that throw/catch uses to handle the 
same problem, naming the destination that you are breaking to?

no, because in the case I am programming a control function I do 
not want to force the users to specify the destination just because 
they are using my control function

There are function attributes to prevent a function from catching 
a return or throw, should there be one for break?

no, because this is a loop business, function attributes cannot help

I understand. That sounds like the way to go.

what do you mean by "the WHILE cycle" though ?

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)