James Mastros wrote:
>
> You seem to like a /lot/ of context markers for
> line-of-flow-control. I think that's somwhat misguided.
I have not anywhere suggested that I'm against POST blocks; in fact
RFC 88 supports the similar "always" concept mentioned by RFC 119.
I'm just trying to figure out exactly how they should work.
> Moreover, I see no need to declare at the beginning, middle, and
> end of a block that there's some exception handling/out of order
> code going on.
Agreed. I don't want to go overboard either. I just want to extend
"eval" to become "try" (hey, saves you a character James), so it
can support the semantics of auxiliary catch and finally clauses,
while still leaving good-old eval alone.
> Also, I think that the syntax of exception processing should be
> minimial [...] because the important things should stand out
> more -- that's why we support both leading and trailing ifs.
Here I disagree. I think indicating the presence of an exception
handling scope should be made to stand out quite a lot, because I do
think it's quite important. It's, well, exceptional.
> > - 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; };
>
> I like this MUCH better.
So do I, that's why I mentioned it as an advantage of the technique.
As long as the order in which you want the Done()s to be called
matches the order defined by the semantics of multiple POST blocks.
> I'd get rid of the caps on POST if I could, but that would be
> breaking tradition for naming magical things.
Well, we do use lower case "continue". Perhaps lower-case is just
fine for block-level things. I did use "always" in the updated
reference implementation.
> > - The semantics aren't quite the same as "try" [...]
>
> TMTWTDI.
>
> You could even have
> {
> my $a = new A; POST: $a->Done;
>
> ...;
> } catch { f() } finaly { g() };
>
> (In which case, we go with order-encountered: first the POST, then
> the catch (if approps), then the finaly.
Yes, that's how I did it in the updated reference implementation.
> > - If the contents of a POST block raises an exception, how
> > does it affect other POST blocks?
>
> I'd like to poist this rule: Each POST block is independent. If
> one raises an exception, it has no effect on the others (including
> the value of @@). This is equivlent to saying that each POST
> block has an implicit eval {}.
>
> If you want to do somthing if a POST {} block throws, use POSTs
> inside the POST, or any of the other try {} catch {} finaly {}
> things.
Even easier, in the updated reference implementation I just dyamically
convert a POST into a finally and now all of finally's already well-
defined semantics answer my own question.
> > 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).
>
> I don't follow you, neccessarly. Is that what I just said? I'm a
> little bit behind in the jargon.
It's close to what you just said, with the proviso that you must
keep track of $@ after each of the implied evals and then do the
equivalent of die @$ if any of them were true. Things are more
complicated with catches, because a catch that doesn't die means
the implied trailing die *doesn't* get invoked after the post
blocks are finished.
> I'd go with a textual FIFO for danglers (what you have proposed,
> if I read it correctly, then a LIFO on the in-body ones in order
> encountered.
That's what I did in the updated reference implementation, except
that I do the in-body ones before the statement-level clauses.
> > - What about conditional CATCH blocks? What syntax can we
> > use that interacts reasonably well with the rest of Perl?
>
> Hm? POST { if (cond) { somthing } }.
>
> CATCH is just shorthand.
Say the code before the post throws. Now, if cond is true (and
somthing doesn't throw) you do not want to unwind after the post,
because the exception has been cleanly caught. But if cond is false
(or somthing does throw) you do, because it hasn't been. How do you
indicate this using the above notation? During the RFC process,
there was a great discussion about this, with one camp suggesting
that post/finally shouldn't propagate trapped exceptions, because
you can always do it explicitly in every post/finally you write.
Others considered that to be a dangerous proposal, because of how
easy it would be to forget the re-throw in the common case.
The approach taken by RFC 88 was to work out a syntax and semantics
for multiple conditional catch clauses that still makes the easy
easy the helps make the hard possible. In the updated reference
implementation, I dynamically convert "except"s into "catch"s, which
seems to work, so far.
Yours, &c, Tony Olekshy
