[FWP] Re: last() dynamically scoped?

["Mark Mielke" <markm@nortelnetworks.com>]

[I've redirected this BUT I think we're getting away from "fun" here. ... -
V.]

>From fwp-l Sat Apr 14 09:03:33 2001

On Sat, Apr 14, 2001 at 05:34:59PM +0200, "Abigail" wrote:
> On Sat, Apr 14, 2001 at 10:18:40AM -0400, Mark Mielke wrote:
> > On Thu, Apr 12, 2001 at 05:17:48PM -0400, "Chris Nandor" wrote:
> > > At 22:08 +0100 2001.04.12, Graham Barr wrote:
> > > >That is because a "bare" block is a loop that is executed once.
> > > I really want to quote something from Alice in Wonderland here ...
> > > Abigail, thanks for the patch.
> > But a bare block is different from a non-bare block.
> >     $ perl -we '{ if (1) {last} print "1\n" } print "2\n"'
> >     2
> This is exactly what Graham means.
> And what do you mean, different from a non-bare block?
>       $ perl -we 'while (1) { if (1) {last} print "1\n" } print "2\n"'
>       2

   if (condition) block     => if (condition) block

   block                    => for (1) block

"{ ... }" acts differently as a block by itself, than a block qualified by
other than a loop construct.

I consider this just one more perl'ism.

> > The dynamic scope checking for last() smells very much like a bug kept
> > for compatibility's sake (scanning dynamically at run-time was likely
> > easier to code way back when - not much of a conscious decision based
> > on a functional requirement), and now kept because it looks cute.
> That's just fishing for an argument. Can you back that up with facts?

Explain why else it exists, then. Does it provide *useful* additional
functionality, for all the non-standard, dynamic run-time scanning it
does? Is this *useful* (doubtful) additional functionality worth the
confusion introduced in the documention, and the implementation? Is it
worth the run-time speed hit, regardless of what it how large or small
it might be? Will any real code break by deprecating its use?

>From the other side of the coin, just re-stated, is eliminating this
non-standard, unpredictable (except for those who feel empowered by knowing
the nitty gritty of every single operation in perl), dynamic run-time
scanning, or at least limiting the depth to within the containing
sub-routine, worth simplifying the documentation, making perl easier to
understand, and possibly causing perl to execute more efficiently?

> > I have an inkling that perl6 could achieve a fair amount of efficiency
> > just by eliminating relatively useless contexts such as this one. The
> > perl C compiler certainly does. Loops tend to be critical, and last()
> > being a loop control construct, would also likely tend to be critical.

> > If the context were to be plugged into last() at compile time, the benefit
> > for a really tight loop could potentially be realized at almost every
> > single iteration.

> Bullocks. Tight loops that execute last at every iteration aren't tight.
> Loop optimizations are important for things done many times. But a loop
> is exited only once.

Unless I'm mistaken, these rules also apply to redo, and next:

    $ perl -we 'sub a { redo } for (1..10) { a(); print "1\n" } print "2\n"'
    Exiting subroutine via next at -e line 1.
    ...

    $ perl -we 'sub a { next } for (1) { a(); print "1\n" } print "2\n"'
    Exiting subroutine via next at -e line 1.
    2

I assume you didn't miss this in your consideration of the statement I
make above. A great deal of code does things like:

    # Only process happy items.
    for (@array) {
        next if $_->{'emotion'} ne 'happy';

        ...
    }


mark

-- 
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca
__________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | SIR Tools
(7H12)
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | Nortel Networks
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

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