World: r3wp

That means that the BIND/copy overhead for BREAK and CONTINUE would 
happen at every call to a loop function, not just FOR, FOREACH and 
REPEAT. And 'break and 'continue would become keywords rather than 
function names, unable to be used for loop-local variables.

LOOP, WHILE, FORALL and FORSKIP don't currently have BIND/copy overhead. 
Which is why they are used a lot in R3 :)

Sorry, I don't mean to go on about that.

Huh?

I certainly enjoyed the discussion, then :)

I don't have the time now to provide examples, I'm afraid, must run 
an errand. Try it yourself and see what you find out :)

Regarding the BREAK usage in REPLACE. You currently have:
    do-break: unless all [:break]
I think that would just become:
    do-break: unless all [:system/contexts/system/break]
(Or wherever the BREAK function would be stored.)

Right, though somewhere else.

The added BIND/copy overhead for loop functions currently not needing 
to BIND their body is certainly true. FOREVER would be another one 
of those.

REMOVE-EACH and MAP-EACH already have the BIND/copy overhead though.

As do most other loop functions, I guess (FOREACH, FOR, REPEAT, etc.).

Only verified it for FOREACH yesterday and assumed that the other 
loop functions that need binding would also copy.

Yup. But not all loop functions need binding, only the ones with 
a lit-word argument with a doc string that says "will be local" or 
some such.

Ah, REPEAT doesn't say that. I should submit a documentation bug 
report.

But all the loop functions that take a word argument have BIND/copy 
overhead, and the rest don't.

Binding: foreach, repeat, remove-each, map-each
Not binding: forever, loop, while, until, forall, forskip

btw, map-each is a burden, adding blocks by default.
Should be an option:  'map-each/only' to insert blocks,
Like other actions creating blocks do.

Already proposed in CureCode, and the R2 2.7.7 version does that 
already.

Andreas: what you ask for has been discussed extensively when R3 
was started, by me, Ladislav and Carl. There are a number of disadvantages 
to that, starting from the fact that you need to bind/copy a lot 
more than you do now (eg. inside CATCH). It would also, unfortunately, 
not work in cases like this:

f: does [throw 'something]
catch [f]

Andreas: "I think that RETURN, EXIT and BREAK, CONTINUE should be 
only available in their respective contexts (functions, and loops)." 
- that is what I preferred too, but Carl did not like it (binding 
takes time).

Nevertheless, at least for Return and Exist this does not look like 
an issue, since binding is likely to occur anyway in these cases

Exit is what I meant above

and, the speed difference for Return and Exit may still exist, but 
only if the respective function does not have any parameter

I think that the implementation of improved error causation as described 
by Brian in bug#1506 would be very worthwile and should be pursued.

 - again, this is a thing I discussed with Carl quite long ago, but 
 it seems, that Carl disliked the fact, that the implementation would 
 have to be more complicated, than it currently is, while the effect 
 Sunanda would like to achieve is probably achievable even now

Do you really think it would complicate implementation much?

Thanks for your feedback, in any case.

not me, it is what Carl thinks, if I understood him well

I have to confess, I'd love to read through those discussions (if 
actually were in writing :).

Carl says he is going to work on the documentation about how errors 
work.

I guess that means he has no intentions of improving error causation?

No, it just means that he wants to start the conversation from a 
good baseline.

Fair enough.

We've been able to find out a lot from stuff posted so far and the 
scientific method though :)

I think a lot of the problems would be solved by just letting developers 
plug in their own recovery code into the console handler, and that 
would be more efficient too.

Yes. Or more generally, a special CATCH version (along with a proper 
predicate) that allows us to set up our own catch-all default handler.

You can already have a catch-all handler:

do does [catch [attempt code]]

add a loop 1 somewhere :-)

>> do does [loop 1 [catch [attempt [1 / 0]]]]
== none
>> do does [loop 1 [catch [attempt [exit]]]] 
>> do does [loop 1 [catch [attempt [return 10]]]]
== 10
>> do does [loop 1 [catch [attempt [break]]]]    
>> do does [loop 1 [catch [attempt [break/return 10]]]]
== 10
>> do does [loop 1 [catch [attempt [throw 10]]]]       
== 10
>> do does [loop 1 [catch [attempt [throw/name 10 'something]]]]
== 10

(this was R2 but barring bugs it should be the same on R3)

Yes, except for bug#851, which creates a no-catch situation

(and, you omitted Try)

Ok, let's start here:

http://www.rebol.com/r3/notes/errors.html

Ladislav: actually, I agreed with you.  RETURN and EXIT should be 
definitionally scoped!

PS: I've always agreed on that.  The question is how best to implement 
such a thing.

doc says "preformed". intentional?

typo!

I think my fingers type "reform" on their own, so "preform" is automatic.

:-)