On Mon, Feb 12, 2001 at 01:58:57PM -0700, Tony Olekshy wrote:
> - 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.
You seem to like a /lot/ of context markers for line-of-flow-control. I
think that's somwhat misguided. Perl already has a fair number of
out-of-line control semantics. DESTROY, overloaded operators, and other
CAPITAL subs come to mind. 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. If you want to understand a block of
code, reading everything textualy within the curley braces should be a
_minimum_, in which case, the word POST is plenty.
Also, I think that the syntax of exception processing should be minimial,
not only because I'll use it more if it's an extra 5 keystrokes instead of
an extra 15, but because the important things should stand out more --
that's why we support both leading and trailing ifs.
> - 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. Even better (IMHO) would be:
my $p = P->new; POST: $p->Done;
my $q = Q->new; POST: $q->Done;
That only gets rid of one char (the ; after the ->Done;s is already optional
as the last statement in a block), but it looks much less crowded to me.
I'd get rid of the caps on POST if I could, but that would be breaking
tradition for naming magical things.
> 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.
You could always say:
my $p = new P;
my $q;
try {$q = new Q};
POST: $q->Done;
POST: $p->Done;
A little on the messy side, but workable.
> - 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. (I don't think there should be a try keyword
neccessary at the top. (Though if present, it should be a warning not to
have any danglers on the end of the block.))
> - 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.
> 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.
> - 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
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.
BTW, when I say order encountered what I mean is that for this:
for (1, 2) {
POST {print "2\n"} if ($_ == 2);
POST {print "1\n"} if ($_ == 1);
print "$_\n";
}
Will output:
1
2
2
1
because we hit the 1 POST block in order-of-execution first, even though it
was second in textual order.
> - 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.
> - What's the return value? With RFC 88 you can say:
The return value is undef (or empty-list) until you hit a return statement.
If the code dies before returning, then it stays undef/() unless somthing
run after that (IE a CATCH/POST/catch/finaly/whathaveyou) returns. (And if
it does, that blocks all execption processing.)
You can mess with the return arbitrarly if we support return-stack visiblity.
-=- James Mastros
--
"All I really want is somebody to curl up with and pretend the world is a
safe place."
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
