World: r3wp

This would then leave us with the "classical" Common Lisp-style use 
of named catch/throw for non-local exits. And for this use-case, 
a definitionally scoped name would certainly be the right thing to 
do, imho.

Maarten and I used a named throw in a proejct for Qtask, but I don't 
use it much. The question is, *should* we use it more, and what are 
the scenarios? It does make some handling read cleaner to me. 

Maybe Carl can say what he envisioned when he designed it.

Ladislav, your B-CATCH/B-THROW example is similar to what I suggested 
in an earlier comment, but in code form. Nice code :)

And I use names CATCH and THROW.

I never tried to catch a named throw without a named catch. If that 
is possible, that is a major bug and should be reported.

It's possible in R2. CATCH returns the name it caught.

It's possible in R3 as well. I'll report it later.

Extept CATCH returns the value, not the name. Even worse.

Andreas, in R3 :result means GET/any 'result.

Sorry, Ladislav mentioned that already.

Is it a bug, or by design though? i.e. it's a general catch. If the 
name gets lost on a named throw, that seems an obvious oversight 
in the design.

That sounds like an error that should be reported by the console. 
A named throw that doesn't have a corresponding named catch should 
be treated like it doesn't have a catch at all.

We use THROW/name to write sandboxed replacements for the unwind 
functions, non-local dynamic escape functions, etc. But that only 
works if CATCH doesn't catch it.

If that was the original design intent, then I agree.

Reported in bug#1518.

Andreas, the meaning of "non-local" we have been using is code that 
is *not* in a nested block or paren. Instead, the code is in another 
function, a block defined elsewhere, whatever. Definitional scoping 
will only work for local code, meaning code that is in nested blocks. 
We have to define locality relative to the catch, not the throw, 
because the catch function is what defines the scoping.

Gregg, CATCH is not a general catch: There is already the /quit option 
that makes it catch more than it normally would.

Steeve, you might be amused to find out that the DO intrinsic currently 
depends on bug#1509 and does need a [throw] attribute. Though it 
still wouldn't work with definitional RETURN because of binding issues. 
C'est la vie.

I'm working on an FIRE effect for R3, that's how I might be amused 
:)

Brian, if a simple CATCH should not catch named throws then we need 
a CATCH/ALL (not sure if /QUIT should be it).

Gabriele, Brian requested such a thing (CATCH/ALL) as bug#1520.

Though he wants bug#1520 to catch all other unwinds (BREAK, CONTINUE, 
RETURN, EXIT) as well, to which I see no merit.

The advantage to that is because on those rare occasions when you 
actually need to catch all THROW and THROW/name unwinds, you most 
likely need to catch the rest too. You might note that the emergency 
exceptions - HALT, QUIT/now, errors - aren't proposed to be caught, 
because the cleanup code would likely interfere with error recovery 
code or the debugging process.

Most of the time you really don't want THROW/name caught by code 
that it isn't intended for. When you really want to catch off-topic 
stuff, you want to catch everything.

However, HALT is used for debugging (which is why CATCH/quit doesn't 
catch it), QUIT/now is supposed to always quit, and you want errors 
to get through so you see them, so those make sensible exceptions.

Can someone else confirm if they get a problem with the following 
ajoin [newline "blah" crlf]

I don't get the problem on windows but do get it on my webhost (linux)

It looks good here on Windows. What problem do you see?

yeah works find on windows

Can you copy the Linux output here?

(I have a theory, but need confirmation)

recreating - hold on

weird - this time it works.

before I would get "^^/blah^M^/"

I would get a double ^

Strange.

yeah not sure why

Heisenbug?

?

It means a bug that goes away when you observe it (or go looking 
for it). Referring to Heisenberg's Uncertainty Principle.

ahhh yeah

Andreas, I put a comment in bug#1520 that should deal with your concerns. 
Take a look.

R2 console allows this: %"_%test%_.r"  But R3 does not. You have 
to use the escaped version: %"_%25test%25_.r"

Right. That was fixed in R3 recently.

Cool. Thanks.

Just to make it clear: The behavior you describe in R3 was the result 
of the fix :)

bug#1443 to be specific.

Though for file! literals it was like that before, afaik. #1443 extended 
that to email! and url! literals.

I understand your take on Carl's proposal for a change in RETURN 
and EXIT scoping, but it needs some work before it can do the job. 
For one thing, if you have dynamic as an option (or a default) there 
is still the need for something like R2's [throw] attribute. And 
if definitional is an option, not the default, then I'm having a 
lot of trouble justifying that option, especially since it doesn't 
solve the [throw] issue or bug#1506. It seems to me that the main 
reason for definitional is to make a simpler default for less advanced 
developers. If it's an option that the user has to chose, it doesn't 
serve that purpose. And if it's an option that gets conflated with 
the option to specify a typespec for the return value of the function, 
then this is going to get Fork furious about making REBOL more confusing, 
and he'll be right this time.

how about this, is it intended?
>> f:  func [self] [self]
** Script error: duplicate variable specified: self
** Where: make func
** Near: make function! copy/deep reduce [spec body]