Re: $a in @b (RFC 199)
David L. Nicol wrote: This ability to jump to "the right place" is exactly what exception handling is for, as I understand it. Exceptions allow us to have one kind of block and any number of kinds of exit mechanisms. If qC(last die return) are all excpetions, the can travel up the call stack until they find the appropriate handler. Kinda. "Exceptions" are supposed to be for exceptional situations only; return is none such. last/next/redo isn't really, either. And I strongly oppose having perl handle user-raised exceptions. But the "longjump" idea is right; so I propose that we lump these things together not as "exceptions" (though they may be implemented internally that way), but as "jumps". But I think the point is important, that the various kinds of blocks, and their respective, yea, defining, exit mechanisms, not be confused or conflated. We just need to clear up what kind of block grep/map use: either a true sub (which I favor), or a distinct kind, with its own early exit keyword(s). -- John Porter We're building the house of the future together.
Re: $a in @b (RFC 199)
'John Porter' wrote:
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
In the odd parallel universe where most perl 6 flow control is handled
by the throwing and catching of exceptions, the next/last/redo controls
are macros for throwing next/last/redo exceptions. Loop control
structures catch these objects and throw them again
if they are labeled and the label does not match a label the loop control
structure recognizes as its own.
...
In a nutshell, there are different kinds of blocks, and their
escape mechanisms are triggered by different keywords.
By unifying the block types, and making the keywords work across
all of them, I'm afraid we would lose this ability to jump up
through the layers of scope to "the right place".
This ability to jump to "the right place" is exactly what exception handling
is for, as I understand it. Exceptions allow us to have one kind of block
and any number of kinds of exit mechanisms. If qC(last die return) are all
excpetions, the can travel up the call stack until they find the appropriate handler.
The "traveling up the call stack" can even be optimized to a per-thread table of
what the appropriate handler is for the most commonly used types.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
