Re: POST blocks (like END, but in a sub or sub-like scope)
Nicholas Clark wrote:
> on the other hand, I'll argue the other side that
>
> {
> my $flag
> open FOO, " ...
> }
> post {
> close FOO if $flag;
> }
>
> is clearer because the tidy up doesn't visually get in the way of the flow
> of what you're doing, and you can see what $flag is meant to be
How is
$flag=1
clearer than
POST{close FOO;&dropLock}
in this example? I don't think the consistency issue is strong enough.
We are also being inconsistent by not suggesting a PRE which would be
analogous to BEGIN and would run at the beginning of a sub even though
it is defined halfway into it. For interior blocks, a label would
be used to say which block we're firing after. Or we always use sub
blocks and that's that.
Re: POST blocks (like END, but in a sub or sub-like scope)
On Wed, Feb 07, 2001 at 05:15:41PM -0600, David L. Nicol wrote:
> Nicholas Clark wrote:
> >
> > On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
> >
> > > sub has_post_blocks{
> > > my $i = 3;
> > > post { print "i ended up as $i"};
> > > my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
> > > my $j = 2;
> > > post { print "j ended up as $j"};
> > > ...
> > > };
> > >
> > > might only print the message about i when arg1 is too small. This would
> > > allow informational messages to be declared at the beginning, for instance.
> > >
> > > It would be implemented by pushing the post block onto the list of things
> > > to do at scope exit, at run time.
> >
> > I quite like this idea. (I certainly like the ability to say "clean up this
> > thing at the end of scope whatever exceptions may happen)
> >
> > But part of me feels it should be a POST block.
> > Because it's behaving much like CHECK or END
> >
> > Nicholas Clark
>
>
> Do you agree that they shouldn't get tacked on until execution passes their
> definition, unlike END blocks which get appended when they are parsed?
It makes them far more useful as tidy up things if they are tacked on at
runtime, not compile time.
The sort of job I'm thinking of is "release this lock" or "close this file"
which you don't want to both with if you never got that far into the sub
You can do it at the moment by making a object where DESTROY does your
cleaning up, but it's a lot less clear having your cleanup code somewhere
else [hmm. I never considered passing an object an anonymous sub for it
to run at DESTROY time...] than having the cleanup code nearby
Of course if these hypothetical POST blocks did get tacked on at compile
time you could achieve the run time effect by having a flag that you don't
set until needed
{
my $flag;
open FOO, " perl -nle 'print 0; $_ and eval {BEGIN{print 1};END{print 2}}; print 3'
>
> only prints one 1 and one 3.
did you mean 2?
Nicholas Clark
POST blocks (like END, but in a sub or sub-like scope)
Nicholas Clark wrote:
>
> On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
>
> > sub has_post_blocks{
> > my $i = 3;
> > post { print "i ended up as $i"};
> > my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
> > my $j = 2;
> > post { print "j ended up as $j"};
> > ...
> > };
> >
> > might only print the message about i when arg1 is too small. This would
> > allow informational messages to be declared at the beginning, for instance.
> >
> > It would be implemented by pushing the post block onto the list of things
> > to do at scope exit, at run time.
>
> I quite like this idea. (I certainly like the ability to say "clean up this
> thing at the end of scope whatever exceptions may happen)
>
> But part of me feels it should be a POST block.
> Because it's behaving much like CHECK or END
>
> Nicholas Clark
Do you agree that they shouldn't get tacked on until execution passes their
definition, unlike END blocks which get appended when they are parsed?
perl -nle 'print 0; $_ and eval {BEGIN{print 1};END{print 2}}; print 3'
only prints one 1 and one 3.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Pedestrians always have the right of way
Re: assign to magic name-of-function variable instead of "return"
On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
> sub has_post_blocks{
> my $i = 3;
> post { print "i ended up as $i"};
> my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
> my $j = 2;
> post { print "j ended up as $j"};
> ...
> };
>
> might only print the message about i when arg1 is too small. This would
> allow informational messages to be declared at the beginning, for instance.
>
> It would be implemented by pushing the post block onto the list of things
> to do at scope exit, at run time.
I quite like this idea. (I certainly like the ability to say "clean up this
thing at the end of scope whatever exceptions may happen)
But part of me feels it should be a POST block.
Because it's behaving much like CHECK or END
Nicholas Clark
Re: assign to magic name-of-function variable instead of "return"
At 05:07 PM 2/7/01 -0500, John Porter wrote: >Peter Scott wrote: > > Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine > that > > the following block is going to be subject to exception handlers which > will > > immediately follow as siblings of the block. > >O.k. That makes sense if some blocks can be try blocks (by adding the >approprate decoration) and some aren't. >But I don't see the advantage of it if any and every block is >implicitly a try block. Me neither. I don't want that. -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
John Porter wrote:
> 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.
So if a post{} block could appear anywhere inside a block, like an END{}
block inside a program (or an eval"" text?) and mean "do this code on
leaving this block, but before scope destruction (which might be arbitrarily
deferred)" would we call the post blocks that hadn't been reached, on exiting?
I think not:
sub has_post_blocks{
my $i = 3;
post { print "i ended up as $i"};
my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
my $j = 2;
post { print "j ended up as $j"};
...
};
might only print the message about i when arg1 is too small. This would
allow informational messages to be declared at the beginning, for instance.
It would be implemented by pushing the post block onto the list of things
to do at scope exit, at run time.
testing eval"END{...}"...
perl -nle 'print 0; $_ and eval "BEGIN{print 1};END{print 2}"; print 3'
stacks up all the C blocks until you give it an EOF, rather than
doing them on exiting the eval space.
BEGIN is not at this time capable of backing up time to before I entered
a true value, so it prints out the 1 as soon as it knows it is supposed to.
Re: assign to magic name-of-function variable instead of "return"
Peter Scott wrote: > Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that > the following block is going to be subject to exception handlers which will > immediately follow as siblings of the block. O.k. That makes sense if some blocks can be try blocks (by adding the approprate decoration) and some aren't. But I don't see the advantage of it if any and every block is implicitly a try block. -- John Porter
Re: assign to magic name-of-function variable instead of"return"
> Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
> the following block is going to be subject to exception handlers which will
> immediately follow as siblings of the block. Somewhat as I would look at
> an if...elsif...else construct, it helps me put the block in context as I'm
> reading it and also look ahead fo those handlers. I prefer this to
> discovering a handler as I'm reading and then looking for the enclosing
> block, or coming across an undecorated block and scanning to see if this is
> because it has embedded handlers or is to create a closure, or to use a
> redo, or...
like
eval { SomethingThatDies()};
if $@{
$@ =~ /case1/ and DealWithCase1 and return;
$@ =~ /case2/ and DealWithCase2 and return;
$@ =~ /case3/ and DealWithCase3 and return;
die "Unhandled case $@";
LABEL:
};
$@ gets reset at the next eval. I assume these things
nest appropriately, and $@ starts as null inside an eval
and evalling something inside there that dies does not
affect external ones. Testing
perl -le 'eval{eval{die "i"};print $@};print "now:$@\nok"'
yup.
Re: assign to magic name-of-function variable instead of "return"
At 02:17 PM 2/7/01 -0500, John Porter wrote:
>Peter Scott wrote:
> >
> > I want the 'try' there for my sake, not Perl's; ... it
> > helps alert me that the following block is subject to non-local control
> > flow rules.
>
>Huh? Down that road lies the Java madness.
>
> eval {
> foo();
> };
>
> sub foo {
> bar();
> }
>
> sub bar {
> die $barney;
> }
>
>All three of these blocks are "subject to non-local control flow rules",
>including the body of foo.
Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
the following block is going to be subject to exception handlers which will
immediately follow as siblings of the block. Somewhat as I would look at
an if...elsif...else construct, it helps me put the block in context as I'm
reading it and also look ahead fo those handlers. I prefer this to
discovering a handler as I'm reading and then looking for the enclosing
block, or coming across an undecorated block and scanning to see if this is
because it has embedded handlers or is to create a closure, or to use a
redo, or...
--
Peter Scott
Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
Peter Scott wrote:
>
> I want the 'try' there for my sake, not Perl's; ... it
> helps alert me that the following block is subject to non-local control
> flow rules.
Huh? Down that road lies the Java madness.
eval {
foo();
};
sub foo {
bar();
}
sub bar {
die $barney;
}
All three of these blocks are "subject to non-local control flow rules",
including the body of foo.
--
John Porter
Re: assign to magic name-of-function variable instead of "return"
At 09:59 AM 2/7/01 -0500, John Porter wrote:
>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.
I want the 'try' there for my sake, not Perl's; I don't care whether some
other languages couldn't parse the block without the word, but for me, it
helps alert me that the following block is subject to non-local control
flow rules.
I'd rather have the 'try' there for the same reason I want to see the 'do'
in "do { ... } while ..." (well, leaving aside the fact that it would be
unparseable without it). But I certainly understand your preference.
--
Peter Scott
Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
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). Funny, during the perl6 RFC period, during the discussion of the exception handling RFCs 88 and 119, you were trying to convince me that the always capability should be a separate RFC from the exception handling RFCs. Naturally I respect your right to change your mind, and argue the other side of the story for a while... I just felt the need to point out to the list that you seem to want it both ways. In this excerpt from an email during that discussion, you started a whole new thread to suggest explicitly separating except and always from exception handling RFCs (note the subject line), and suggest renaming "always" to "finally" because there would be no confusion between the two different finally clauses (one INSIDE exception handling control structures, and one INDEPENDENT of exception handling control structures) because they could easily be distinguished without the parser getting confused. > Subject: Why except and always should be a seperate RFC. > Date: Wed, 23 Aug 2000 22:09:23 -0600 > From: Tony Olekshy <[EMAIL PROTECTED]> > ... > 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. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers - Stuff below this added by NetZero - Shop online without a credit card http://www.rocketcash.com RocketCash, a NetZero subsidiary
Re: assign to magic name-of-function variable instead of "return"
Johan Vromans <[EMAIL PROTECTED]> writes:
[...]
> But I think this is getting ridiculous. $slightly_joking++; I'd
> propose a much nicer and cleaner concept:
>
> sub readit {
> open F ... ;
> prog1 {
> scalar();
> close F;
> }
> }
>
> 'prog1' executes all expressions in the block, and returns the result
> of the first expression. Of course, we also need prog2, prog3, and so
> on ... $slightly_joking--;
If you're going to reimplement Lisp poorly, at least reimplement the
right bits of Lisp poorly. In this case, you want unwind-protect, not
prog1. You can see the difference e.g. when throwing.
Here's the Emacs Lisp documentation of unwind-protect:
`unwind-protect' is a built-in function
Documentation:
Do BODYFORM, protecting with UNWINDFORMS.
Usage looks like (unwind-protect BODYFORM UNWINDFORMS...).
If BODYFORM completes normally, its value is returned
after executing the UNWINDFORMS.
If BODYFORM exits nonlocally, the UNWINDFORMS are executed anyway.
You can read the relevant bit of CLtL2 at
http://www.supelec.fr/docs/cltl/clm/node96.html .
> All that POST and such do, is obfuscate the flow of control. I doubt
> that outweighs the small benefits.
However, unwind-protect is useful. It's either use that or use
something destructor-related. That just sits on top of some
unwind-protect-like hack in the internals.
--
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658117 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: assign to magic name-of-function variable instead of "return"
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.
Re: assign to magic name-of-function variable instead of "return"
Johan Vromans wrote:
>
> Would the POST be executed if the open fails? Why? Why not?
Of course. It's a post-handler on the sub.
> All that POST and such do, is obfuscate the flow of control.
No more so than contine{} on a loop, or END{} in a file, or DESTROY{}
in a class.
--
John Porter
You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of "return"
Bart Lateur <[EMAIL PROTECTED]> writes:
> The place where it would be put, would be irrelevant.
>
> sub readit {
> POST {
> close F;
> }
> open F, "< $f" ...
> scalar()
> }
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, "< $f" or die;
scalar()
}
But I think this is getting ridiculous. $slightly_joking++; I'd
propose a much nicer and cleaner concept:
sub readit {
open F ... ;
prog1 {
scalar();
close F;
}
}
'prog1' executes all expressions in the block, and returns the result
of the first expression. Of course, we also need prog2, prog3, and so
on ... $slightly_joking--;
All that POST and such do, is obfuscate the flow of control. I doubt
that outweighs the small benefits.
-- Johan
Re: assign to magic name-of-function variable instead of "return"
On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote:
>RFC 271 handles this. Your example would be:
>
>sub readit {
>open F, "< $f" ...
>scalar()
>}
>post readit {
>close F;
>}
The connection between these two things is not strikingly obvious. I'd
like it better, if you put the post thing inside the sub readit's
contents. It can even be anonymous.
sub readit {
open F, "< $f" ...
scalar()
POST {
close F;
}
}
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, "< $f" ...
scalar()
}
--
Bart.
