World: r3wp

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)

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.