Tony Olekshy wrote:
>
> I think "always" should be part of an explicit statement, such
> as "try", not some implied property of block structure introduced
> by a dangling clause (inside or outside).
Why? For that matter, why must "try" itself be explicit?
It says, "I'm probly gonna put some exception catchers on this block,
so if I do, choke fatally if I haven't put the magic word up here."
This strikes me as exceedingly un-Perlish, though of course quite
natural in B&D languages like C++ and Java.
> Once you have an always clause, it has to be invoked during stack
> unwinding caused by the raising of an exception.
Yes, that's Perl: it does the hard stuff for you.
> This means there
> is an implied goto-on-exception pending throughout the scope
> affected by the always clause. This is not like if/else, for, or
> while, which are all marked up front, and only have explicit variant
> flow control. It is like eval, but note that eval is marked up
> front too.
Note that END{} and BEGIN{} require no formal introduction.
You can put them anywhere you want, and they run at the proper time.
Even continue{} is an implicit goto. And it requires no introduction
either.
> Like eval, the beginning of the scope for non-local flow control
> (such as always and catch) should be explicitly delimited, typically
> by using a keyword like try.
Back into the ivory tower, wench! :-)
A left-curly is all the introduction I need.
> Say you run into one of the
> cross-product constructs in some code. Is it clear to you what
> the scope and semantics are? Is it clear when always applies
> to the foreach block, and when it applies to the catch block,
> and when it applies to the foreach statement?
Obviously we can't mix the two syntaces. Only having catchy blocks
inside prevents the ambiguity you're talking about.
Assuming no dangling blocks, what about the following is ambiguous?
> foreach ... { ... catch { ... } always { ... } }
> What about the try/finally cases? It's pretty clear, IMHO,
> that the catch and finally clauses apply to the try statement,
There is no try, there is only do. :-)
> previous blocks are critical, because under various circumstances
> blocks need to be triggered by exceptions raised in previous
> blocks.
If the blocks were lexically nested, we would avoid entirely this
"previous block" mess.
--
John Porter
You can't keep Perl6 Perl5.