Tony Olekshy wrote:
> Other than for the except and always clauses, RFC 199 is very
> similar to RFC 88. I like the idea behind except and always,
> but I think the proposed implementation could be dramatically
> simplified.
>
> The first thing to realize is that just because 119 doesn't say
> "try" the doesn't mean it isn't there, it's just implied.
This is true. RFC 119 explicitly suggests that _all_ code be in an
implicit try block, as it includes definitions for implicit catch
phrases to be included at the end of the main scope. This causes
_absolutely no effect_ on any program that doesn't use the RFC 119 throw
keyword, and there are no programs today that do so. The first effects
of RFC 119 are when a programmer chooses to use one of its features.
And no other features are affected by that choice. It is orthogonal to
all other features of Perl.
> To my
> understanding, in order to be able to try, catch, or finally at all,
> one must pre-arrange to have changed the exit-sequence code for a
> block that has try, catch, or finally semantics, whether implicit
> or not, because one has to do the stack unwinding thingy for such
> blocks.
Well, that's true if you assume that the normal exit sequence for a
block does not support stack unwinding. And that assumption is true for
languages that don't have exception handling built in, but rather tack
it on. And that same assumption is true for some languages that build
in exception handling, but attempt to limit the scope of when it
applies. Perl5 is such a language. Perl6-including-RFC-119 might
support exception handling as a normal part of the exit sequence for a
block.
> That's why some references mention that it may be difficult
> to do a local goto across a non-local unwinding boundry. On the
> other hand, Perl is not so tied to hardware, so this may not be
> difficult to arrange at all.
Especially in perl6.
> Whether or not local gotos out of unwind flow-control blocks can
> be implemented does not impact the usefulness of the concepts of
> except and always. If those gotos can be done they will be,
> otherwise they won't; it will have the same impact on 88 and 119.
Correct.
> So, lets say we had a syntax like this:
>
> {
> my $foo = $bar always <expr>;
> my $foo = $bar always <block>;
> my $foo = $bar always <code_ref>;
> ...
> }
>
> The given <expr>, <block>, or <code_ref> would be evaluated just
> before its associated lexical variable goes out of lexical scope,
> including due to unwinding.
I don't consider the lexical variables to be particularly tied to the
always block. Because the first statement in each of these examples
defines a lexical variables, in some sense it is tied, but the always
block is more particularly tied to the statement; the statement in these
examples happens to define a new lexical variable. So there is nothing
wrong with your statement, but it draws a closer relationship between
the defined variables and the always clause than would always exist.
> If some action is to be taken on end-of-scope, but only if an
> exception is being caught (like RFC 119s "except") it can simply
> be coded like this:
>
> my $foo = $bar always { $@ and catch_it($foo); };
Presuming that exceptions set $@, and that the truth of $@ reflects the
existance of an exception (both of which are true for RFC 88, but
neither of which are currently required to be true for RFC 119), then
you are correct, it could be coded that way.
"except { ... }" is syntactic sugar for "always { if (<we are unwinding
the stack due to an exception>) { ... }}"
This is nice syntactic sugar, I like it. It hides the logic in <>
above, which hopefully is simple, but of which novices need not be
aware.
> because in an always (like in a finally in RFC 88), defined $@
> indicates whether an exception is being handled, or normal local
> processing is taking place.
This is assuming facts not in RFC 119, regarding its use of $@.
> This RFC would need some notes about where exactly "always" hooks
> into the rules described in a generic mechanism like RFC 88, and
> perhaps an RFC-88 style mechanism hook for invoking a callback
> whenever an "always" is entered, like this:
>
> try on_always_enter => sub { ... }, { ... }
>
> Note that since RFC 88 uses a "try" keyword to establish the
> context in which a "finally" keyword is expected, and since
> the my $foo examples above don't have such context, "always"
> can probably be renamed "finally" without the parser getting
> confused about RFC 88's finally.
>
> And that would pretty much be my version of the "always" RFC.
>
> Yours, &c, Tony Olekshy
Generally, assuming RFC 88, that'd be a pretty reasonable "always" RFC.
As noted above, "except" is, in my opinion, helpful syntactic sugar.
As noted in other posts, you can eliminate your finally clause from RFC
88 altogether, because it is one and the same with "always" (especially
an "always" that is renamed "finally"), and should, by your standards,
be a separate RFC.
So far, neither of us has made "finally" or "always" a separate RFC. It
is a useful, but separable part of an exception handling mechanism. RFC
88 (so far) ties it to a "try" statement; RFC 119 (so far) doesn't.
Both include the same sorts functionality as part of the larger RFC.
I don't think we have anything to disagree about here.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
