World: r3wp

Absolutely right, Ladislav. There needs to be such a definition, 
or at least a comparison. I was going to add one.

Not to your page of course :)

Probably an example (or two) is preferable

This would be part of the issues section, so it would be mostly prose. 
This is part of a strategy to remove most of the prose from the other 
sections, so there will be more room for examples.

btw, the dynamic variable, just solved a long standing binding problem 
riddle I had with classed based instantiation of objects in R2.  
when I had talked to Carl about it at the last devcon, even he couldn't 
explain it... so its a very nice thing to get "out in the open".

With parse being a dialect on it's own, BREAK in PARSE can be separate 
from BREAK in loops. So that's not really an argument to keep dynamic 
BREAK (for loops).

That way the issues can be laid out clearly, so the rest of the page 
can just link to the appropriate issues sections instead of repeating 
things.

PARSE doesn't bind the code in its parens - that's regular REBOL. 
Parse also can't know ahead of time which blocks it will be treating 
as rules, because it uses dynamic scope for the whole dialect.

Definitional returns or escapes rely on lexical scope. If you don't 
have lexical scope, you don't have the ability to do definitional. 
So what PARSE needs is for the top-level BREAK to be dynamic. And 
if one level is dynamic, we are better off with all levels being 
dynamic, at least for the same escape function. Same goes for definitional.

Thanks for restating the facts. Once again, there's nothing intrinsic 
in PARSE that forces it to use the same BREAK used in loops.

Yes there is: Definitional breaks redefine BREAK to a definitional 
function, and PARSE relies on BREAK being dynamic because PARSE is 
inherently and necessarily dynamic and doesn't rebind anything in 
the parens, nor should it. For that matter, PARSE rules can be reassigned 
in their productions, so PARSE can't even rely on the rules being 
the same thing the next time round.

note that there are two usable BREAKs in parse.    parse [break] 
  vs   parse [(break)]

Use LEAVE-PARSE instead of BREAK for exiting PARSE.

Maxim, there is also parse [return].

See also the change log notes for A98, where the BREAK handling was 
actually introduced:
http://www.rebol.com/r3/changes.html#section-23

Which is not the same as PARSE [(return)], but PARSE doesn't pay 
attention to the bindings of the keywords in its rules, just those 
of the rule names. And in the productions (parens) PARSE can't do 
any rebinding at all because it can't assume that BREAK is referring 
to the same function.

Point is: the behaviour of BREAK in PARSE is not a strong argument 
at all when considering the behaviour of BREAK in loops.

BREAK in PARSE was added as a nice hack, but it certainly is not 
the primary functionality of BREAK.

If it makes sense to change the behaviour regarding the primary functionality 
of BREAK, this cute little hack is the least thing that should stand 
in the way of that change.

The behavior of BREAK in PARSE is the main reason we can get away 
with dropping dynamic return. It's a tradeoff - you get dynamic break 
or dynamic return.

Because we can not use dynamic THROW in PARSE, or what?

Dynamic break is completely irrelevant in the context of parse.

Ladislav wants to get rid of dynamic throw as well.

Yes, but that's one argument, not two.

It is becoming abundantly clear that there is more and more need 
for a comparison section that shows the strengths of dynamic vs. 
definitional, because people seem to not understand that there are 
ceratin classes of code and algorithms (parsing, for instance) that 
can't be expressed with strict lexical scoping. You are giving up 
a lot when you go definitional, so that better stuff not be as important 
in the context where you do it.

better stuff not be as important -> stuff better not be as important

One construct for dynamic scoping is sufficient.

Would we have a WITH-DYNAMIC we wouldn't need anything else.

It turns out that with functions, because of the tasking issues, 
you already have to give up the benefits of dynamic return. So getting 
rid of dynamic return is no loss. The same can't be said of BREAK.

It is only because of tasking issues though - otherwise losing dynamic 
return would be a big deal.

To you, personally.

There are some advantages to definitional return as well, so it's 
a net plus.

As should be obvious by now, there are varying views on that issue.

Yes, based on varying levels of information. My statement is objective. 
It is all a tradeoff, and I have not at any point tried to hide the 
upsides and downsides of both approaches.

I can assert stuff about PARSE because Peta was nice enough to include 
or link to the mathematical proofs on the Parse Proposals page.

So I can say that PARSE is based on dynamic scope with certainty.

No problem with that.

Only that parse does not have any bearing on BREAK for loops.

And I can use those same proofs to apply to other algorithms with 
similar characteristics, and *know* that you gain some abilities 
with definitional scope, and lose others. This is why I know that 
Ladislav's DO-ALL is a loop, and so not wanting BREAK to apply to 
it is more of an opinion than something inherent in its nature. But 
that doesn't mean that the need for that is less.

And yes, I would be satisfied with THROW being dynamic and the rest 
not. But my *bare minimum* requirement for accepting that is to fix 
THROW so it actually works properly, and in many ways it doesn't 
at the moment (all with tickets), and in one way it could work better 
(also with a ticket).

I've just reread a few things and I now truely understand the deeper 
intricasies of this whole discussion... (finally ;-)

I think that the terms dynamic and definitional aren't making comprehension 
easy, especially dynamic.

(phone call)

That is why I prefer lexical instead of definitional. Definitional 
is lexical + faked lexical.

(as terms, not as concepts)

also I think that the word unwind from the error document should 
be used, since that is really is what happends afaict.

used in discussion I mean.

I also prefer lexical, though definitional is more *precise*... ironically, 
I didn't understand dynamic return until I grasped what definitional 
return really was.

in my mind they are *both* dynamic returns... you aren't just falling 
of the function's end, removing from the stack.  

you are *causing* that to happen.

the difference is in the how far they unwind...

Please don't take my mentioning of downsides as being a statement 
of opinion or some kind of taking sides. I only mention them because 
they are real, and must be considered when picking a certain strategy. 
Both approaches have plusses and minuses. If you want to make a rational 
choice then you need to know the issues - otherwise you are just 
being a fanboy.


For instance, I picked the definitional side for returns, without 
the need for a fallback to dynamic, because of a rational evaluation 
of the algorithmic style of R3's functions. And it wasn't until I 
remembered that the tasking issues had already removed the advantages 
that dynamic scoping has over lexical scoping - we just can't do 
that stuff as much anymore, so it doesn't matter if we don't try. 
The same goes for loops, but to a lesser extent - loops aren't affected 
as much by tasking issues so we can still do code that would benefit 
from dynamic breaks, but it still might be a worthy tradeoff to avoid 
needing an option (since we have no such option). But for THROW, 
especially THROW/name, there are things that you can do with dynamic 
throw that you *can't* do with definitional, and those things would 
have great value, so it's a rational choice to make the tradeoff 
in favor of dynamic.