Nicholas Clark wrote:
>
> It makes them far more useful as tidy up things if they are tacked
> on at runtime, not compile time.
If I understand, it is proposed that code like this:
{
Alpha;
POST { Beta };
Gamma;
POST { Delta };
Epsilon;
}
will behave something like this:
{
my @onEnd = ();
try {
Alpha;
unshift @onEnd, sub { Beta };
Gamma;
unshift @onEnd, sub { Delta };
Epsilon;
}
finally {
foreach (@onEnd) { &{$_}(); }
}
}
If so, then I have some observations.
- It does have in-flow presence, so it doesn't suffer from the
problem that "always" has; POST is a statement, not a dangling
clause. That fixes my main complaint with RFC 119. On the
other hand, now there's nothing at the end of the scope to tell
you whether or not have to revisit the whole scope to check if
there are any POST clauses before you advance your mind to the
next statement. Hmm.
- It does solve the dual free problem. Where RFC 88 says:
try { my $p = P->new; my $q = Q->new; ... }
finally { $p and $p->Done; }
finally { $q and $q->Done; }
the proposed method could say:
my $p = P->new; POST { $p->Done; };
my $q = Q->new; POST { $q->Done; };
...
On the other hand, there is no easy way to specify the order
in which $p->Done and $q->Done are invoked, independent of
the order in which $p and $q are constructed. Hmm.
- The semantics aren't quite the same as "try", which
declares exception handling blocks that are active once
try's block is entered, not when the declarations are
passed in the block. Perhaps both mechanisms should be
supported? RFC 88 does suggest that RFC 119 should be
considered independent of RFC 88, not as an alternative
thereto.
- If the contents of a POST block raises an exception, how
does it affect other POST blocks?
In the example above, if $p->Done throws, then $q->Done should
be called, *and* vice versa, *and* unwinding should propagate if
either one threw (or anything else did for that matter, unless
it was caught without the catching throwing).
- What about CATCH blocks (what RFC 88 calls "catch" and RFC 119
calls "except")? What exactly is the interaction between these
dynamic POST and CATCH blocks? We will need a detailed semantics,
along the lines of
http://www.avrasoft.com/perl6/rfc88.htm#Unwinding_Semantics
- What about conditional CATCH blocks? What syntax can we
use that interacts reasonably well with the rest of Perl?
- What's the return value? With RFC 88 you can say:
my $r = try { f() } catch { 0 };
What are the syntax and semantics in the CATCH/POST case?
Perhaps something like:
my $r = do { CATCH { 0 } f() };
Hmm.
Yours, &c, Tony Olekshy
