World: r3wp

Brian, please notice that I am talking about two things in the past 
few messages. I separated those discussions with "---".

The first is the proposal for a change of semantics, which I'm mainly 
interested in as a though experiment.

thought*

Ah, cool. Glad to continue the thought experiment then :)

Great :)

But actually I wanted to leave that experiment for now.

After the "---" I discussed the overhead of the solution you proposed 
on the bug tracker.

And if you re-read that, you will notice that it's precisely what 
you later describe.

Yup.

Except the THROW/name block-of-words thing.

Precisely.

The overhead of which would be more noticeable, but not too severe. 
Some simple heuristics should do fine.

As words are interned anyway, you only need an array of integers 
to store the names.

Btw, non-local code blocks are a common optimization trick in mezzanine 
code, one which shows up a lot in Carl's code. It's probably the 
reason why REBOL supports the concept in the first place. And I've 
written code in REPLACE that uses the BREAK function as a function 
value, though I haven't checked whether other people use this trick 
:)

Let's finish the performance discussion firs t:)

Typical code will have only very few distinct named catches.

That's for sure - I haven't seen it yet in mezzanine code.

So I think the vast majority of cases can be handled by very efficient 
code.

It seems so. I've asked Carl to look at those tickets and chime in, 
so we'll see what he thinks.

Great, I'd really like to see this improved, even if it's only a 
rare corner case.

That said, we can go back to the thought experiment, if you like 
:)

If you want to see how weird really optimized R3 code can get, take 
a look at the source of LOAD and IMPORT - they are probably the most 
heavily optimized mezzanine functions. For the most part the rest 
of the mezzanine code is written for readability and maintainability, 
and the language optimized to make readable code fast. It's a good 
tradeoff :)

I'm well aware of the value of foreign code blocks as such. The interesting 
question, I guess, is how often foreign code is used without re-binding 
it.

Most of the time, actually, otherwise the BIND/copy overhead would 
make it a poor optimization.

Optimization is only one use case, though.

Do you have a succinct example of such a use for optimization purposes?

The nice BREAK trick used in your REPLACE would mostly be unaffected 
by this change, for example.

You'd just use the function value of the (not globally bound) function 
implementing break.

IMPORT uses code blocks as a way of reusing duplicate code, though 
it might not be affected either. And REPLACE would be affected because 
'break wouldn't be bound at the point it is used: Being in a function 
isn't enough, it's outside of the loop. BREAK is used to break out 
of loops, not functions.

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).