Re: last() dynamically scoped? (was Re: [FWP] awww, no fun :()

[Michael G Schwern <schwern@pobox.com>]

I'm CCing this to p5p, too.


On Thu, Apr 12, 2001 at 05:52:00PM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > This isn't about faster, its about action at a distance.  This feature
> > doesn't have any use but for implementing action at a distance.  Its
> > sort of like a reverse goto LABEL.
> 
> That's what throw (die) does in every language.
> This remote last is really just specialized kind of throw/catch.

Yes, but *I* write the throw/catch block (in this case, an eval
block).  I'm aware of it and I'm saying "yes, I do want to alter the
control flow of my loop based on what this subroutine does".  With
last, it just steps in and takes over from anywhere in the code I
call without my consent or even awareness.  Bad.


> > But at least goto has to go to a declared LABEL.
> 
> Come on, it's not like remote last is like a computed goto.

Its worse.  At least I can grep for 'goto' and know something funny is
going on.  Furthermore, goto can only go to a LABEL, and LABELs must
be declared by me, the calling code author.  This last business would
be like having a "goto FILE, LINE".


> > die() inside
> > an eval BLOCK can sort of be seen to do something similar, but its
> > obvious you're expecting it (since you used an eval BLOCK).
> 
> Ah -- what's needed, then, is an adjustment of expectations, not
> of Perl.

No, I do not want to have to be in a constant state of paranoia that
at any moment the rug of control might be pulled out from under me.


> > Finally,
> > there's exit() which is not recommended to use in a subroutine or
> > module.
> 
> By whom?   Ridiculous.

Let's just say its results are a bit more dramatic.  But no, you
really shouldn't use exit() in a library because its untrappable.
There are, of course, exceptions.


> >         while(1) {
> >             foo();
> >         }
> > When will that exit normally (ie. not via a die or exit)?  This should
> > be a simple answer, but you can't know without examining foo() and all
> > routines foo() might call.  This is bad.
> 
> No badder than this, which has exactly the same issues:
> 
>       eval {
>         while(1) {
>             foo();
>         }
>       };

No.  I can look at that and say, "The loop will exit when foo() dies."
The loop author fully expects foo() to die by wrapping it in an eval.
I have a point from which to start tracking down the details of its
flow.


> > All of the above (exit, die... maybe goto) have reasons for causing
> > this caveat.  last() really doesn't.
> 
> Apparently it does.  Adjust your expectations.

What are they?  I've yet to see a really valid use that justifies how
badly and secretly it can muck up control flow.  The examples I've
seen so far can all be replicated just as easily without this magic.


-- 

Michael G. Schwern   <schwern@pobox.com>    http://www.pobox.com/~schwern/
Perl6 Quality Assurance     <perl-qa@perl.org>	     Kwalitee Is Job One
Do not try comedy at home!  Milk & Cheese are advanced experts!  Attempts at
comedy can be dangerously unfunny!

==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe