World: r3wp

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]

(that looks like illustrating your note, that 'self is a keyword)

Nope, it is not intended, it is a bug. Report it.

Only closures and FUNCT/with should define 'self; regular functions 
shouldn't.

Why closures, is it of advantage for closures?

(I do not see it as an advantage, maybe overlooking something...)

The contexts of closures persist outside of the scope of their execution, 
like objects. The contexts of functions don't.

yes, I know that, but does it need to use 'self because of that?

(my closures originally did not use 'self)

Not unless the closure has no arguments, but it doesn't hurt enough 
to get rid of it. On the other hand, we should probably get rid of 
'self binding from FOR, REPEAT, FOREACH, MAP-EACH and REMOVE-EACH 
(it's already been reported).

yes, that looks inappropriate

I would be willing to accept getting rid of 'self binding from closures 
if that is the choice, no big deal.

The 'self bound by FUNCT/with is bound to the object context, so 
it should stay.

'self binding from FOR,
 could you point me to the ticket?

Weird, can't find it. I remember someone reporting it - must have 
been in chat. Report it.

OK

I would myself but don't have the time today (friend in hospital). 
I can refine any tickets later if you like.

OK, no problem

It seems that functions don't bind 'self to the code block, but they 
do reserve it in the function spec. So that's a separate ticket.

yes

And closures don't bind 'self anymore either (I now vaguely remember 
a ticket related to that).

Note: The duplicate variable 'self bug in function and closure specs 
might be dismissed (not by me). It could be necessary for the implementation 
to have an internal 'self in the function contexts; only Carl could 
say for sure.

That seems like more of a gotcha than a bug though.