World: r3wp

Volker: regarding the [throw] function attribute - it is not able 
to influence to which loop the BREAK belongs

I see 'break and 'return as kind of catch/throw. So to me its clear. 
But i may miss something. The old way to build
  my-loop[break]
would still work lexically?

i do not like that a break can break function-nesting.

 - you can always "break out of a function", unless the BREAK implementation 
 is faulty

f: func[][break/return 2]
probe loop 1 [probe f]

Hmm, no error. I do not like that.

:-)

If i want to obfuscate things, i remember that..

In that case lexically could make sense. Easier to see what is broken.

But it would break cleanup-code?

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.