Perl loops should use break, not last

Discussion in 'Perl Misc' started by Jeremy Morton, Jan 29, 2005.

  1. Probably been mentioned before but I fail to see why Perl changed the
    'break' keyword to 'last', in loops. Bear with me on this - it seems
    semantically more accurate to say 'break' - you're immediately breaking out
    of the loop. 'last' makes it sound like the current loop will be the last,
    but not that the execution should be stopped immediately, whereas break
    makes it sound like the latter.

    Where can I propose that this be changed, or break aliased to last, for Perl
    6?


    --
    Best regards,
    Jeremy Morton (Jez)
    Jeremy Morton, Jan 29, 2005
    #1
    1. Advertising

  2. Jeremy Morton

    Matija Papec Guest

    X-Ftn-To: Jeremy Morton

    "Jeremy Morton" <> wrote:
    >Probably been mentioned before but I fail to see why Perl changed the
    >'break' keyword to 'last', in loops. Bear with me on this - it seems
    >semantically more accurate to say 'break' - you're immediately breaking out
    >of the loop. 'last' makes it sound like the current loop will be the last,
    >but not that the execution should be stopped immediately, whereas break
    >makes it sound like the latter.


    I'm guessing, "last" was picked because it's short and it sounds good along
    with "next". Further, "break" could blur things for C people as his
    "continue" friend is already used for something else.

    [crosspost trimmed]


    --
    Matija
    Matija Papec, Jan 29, 2005
    #2
    1. Advertising

  3. "Jeremy Morton" <> wrote in
    news:41fbaeb9$0$26027$:

    [ Removed comp.lang.perl from newsgroups list ]

    > Probably been mentioned before but I fail to see why Perl changed the
    > 'break' keyword to 'last', in loops. Bear with me on this - it seems
    > semantically more accurate to say 'break' -


    I have a sneaking suspicion that you are trolling, but I will indulge
    you anyway. You can think of 'last' as 'this is the last statement to be
    excuted in this loop'. At least, that is why it made sense to me the
    first time I started learning Perl.

    > 'last' makes it sound like the current loop will be the last,


    Your terminology is odd. How can the current loop be the last? How could
    a statement in one loop affect whether or not other loops are excuted?

    Are you saying, if I have:

    my @animals = qw(cat dog dino);

    for my $animal (@animals) {
    last if $animal eq 'dog';
    }

    for my $animal (@animals) {
    print uc $animal, "\n";
    }

    The second loop will not be excuted due to the 'last' statement in the
    first loop.

    I am going to recommend a visit to http://learn.perl.org/ as well as
    reading perldoc -f last.

    Hope this helps.

    Sinan.
    A. Sinan Unur, Jan 29, 2005
    #3
  4. Matija Papec <> wrote:
    > X-Ftn-To: Jeremy Morton
    >
    > "Jeremy Morton" <> wrote:
    >> Probably been mentioned before but I fail to see why Perl changed the
    >> 'break' keyword to 'last', in loops. Bear with me on this - it seems
    >> semantically more accurate to say 'break' - you're immediately
    >> breaking out of the loop. 'last' makes it sound like the current
    >> loop will be the last, but not that the execution should be stopped
    >> immediately, whereas break makes it sound like the latter.

    >
    > I'm guessing, "last" was picked because it's short and it sounds good
    > along with "next".


    That's a good reason to choose a keyword, because it 'sounds good'? Heh.
    It doesn't make semantic sense, and that's far more important IMHO.

    > Further, "break" could blur things for C people as
    > his "continue" friend is already used for something else.


    Yes, I don't quite understand why 'continue' is used the way it is,
    either... that doesn't make much sense. However i'd still rather have
    'break' meaning what it does in most other languages i've come across. You
    don't even have to do away with 'last'... just alias break to mean the same
    thing.

    --
    Best regards,
    Jeremy Morton (Jez)
    Jeremy Morton, Jan 29, 2005
    #4
  5. Jeremy Morton

    Anno Siegel Guest

    [defunct newsgroup comp.lang.perl trimmed]

    Jeremy Morton <> wrote in comp.lang.perl.misc:
    > Probably been mentioned before but I fail to see why Perl changed the
    > 'break' keyword to 'last', in loops. Bear with me on this - it seems
    > semantically more accurate to say 'break' - you're immediately breaking out
    > of the loop. 'last' makes it sound like the current loop will be the last,
    > but not that the execution should be stopped immediately, whereas break
    > makes it sound like the latter.


    It makes perfect sense when you name the loops appropriately:

    line: while ( <DATA> ) {
    next line if /^\s*#/;
    chomp;
    last line if $_ eq '__END__';
    # ...
    }

    What could be clearer? That's the idea behind "next" and "last", even
    if the label is not present.

    > Where can I propose that this be changed, or break aliased to last, for Perl
    > 6?


    I don't believe that's still open for discussion. Look for something
    appropriate at http://dev.perl.org/perl6/lists/ if you want to try anyway.

    Anno
    Anno Siegel, Jan 29, 2005
    #5
  6. On Sat, 29 Jan 2005, A. Sinan Unur wrote:

    > "Jeremy Morton" <> wrote in
    > > semantically more accurate to say 'break' -

    >
    > I have a sneaking suspicion that you are trolling,


    I think you're being rather uncharitable. As far as I recall, "break"
    /was/ the term used in BCPL for effectively the same purpose:

    | causes execution to be resumed at the point just after
    | the smallest textually enclosing loop command

    it says in the old manual.

    But the Perl usage is now well established, and the other arguments
    on this thread are well taken. I doubt there's anything to be gained
    by trying to change the Perl usage now, and I don't see any net
    benefit in it.

    all the best
    Alan J. Flavell, Jan 29, 2005
    #6
  7. Jeremy Morton

    Anno Siegel Guest

    Jeremy Morton <> wrote in comp.lang.perl.misc:
    > A. Sinan Unur <> wrote:
    > > "Jeremy Morton" <> wrote in
    > > news:41fbaeb9$0$26027$:
    > >
    > > [ Removed comp.lang.perl from newsgroups list ]
    > >
    > >> Probably been mentioned before but I fail to see why Perl changed the
    > >> 'break' keyword to 'last', in loops. Bear with me on this - it seems
    > >> semantically more accurate to say 'break' -

    > >
    > > I have a sneaking suspicion that you are trolling, but I will indulge

    >
    > Why does every genuine question to a Usenet group have to be a troll? See
    > this is why I don't often post on bloody Usenet.


    Take it or leave it.

    > > you anyway. You can think of 'last' as 'this is the last statement to
    > > be excuted in this loop'. At least, that is why it made sense to me
    > > the first time I started learning Perl.

    >
    > Yes, that is the only way you can think about it validly. My point is that
    > if 'next' is to mean 'execute the next iteration of this loop', it seems
    > more natural for 'last' to mean 'make this the last iteration of this loop'
    > as opposed to 'make this the last statement of this loop'.


    You mean, the loop body continues to the final "}" before the loop
    ends, like a delayed break? That's an interpretation I wouldn't
    have thought of, just because it would be a rather awkward behavior.
    (If you need the behavior, you can have it with the current working
    of "last", but not easily the other way around.)

    To me, "last" means last, enough, quit. Just like "next", it leaves
    the normal sequence of execution immediately. Your interpretation
    seems overly literal-minded and artificial to me.

    > On the other
    > hand, 'break' does sound natural as you're breaking out of the loop
    > immediately by making this the last statement.


    Only if you are already accustomed to its specific usage in C. "Break
    out" isn't the first thing that comes to mind when I see "break" without
    context. The step from the everyday meaning of "break" to the C-specific
    one is no shorter than it is from the everyday "last" to the Perl-specific
    meaning.

    Anno
    Anno Siegel, Jan 29, 2005
    #7
  8. Jeremy Morton

    Guest

    "A. Sinan Unur" <> wrote:
    > "Jeremy Morton" <> wrote
    >
    > > Probably been mentioned before but I fail to see why Perl changed the
    > > 'break' keyword to 'last', in loops. Bear with me on this - it seems
    > > semantically more accurate to say 'break' -

    >
    > I have a sneaking suspicion that you are trolling, but I will indulge
    > you anyway. You can think of 'last' as 'this is the last statement to be
    > excuted in this loop'. At least, that is why it made sense to me the
    > first time I started learning Perl.
    >
    > > 'last' makes it sound like the current loop will be the last,

    >
    > Your terminology is odd. How can the current loop be the last?


    By not executing another time.

    > How could
    > a statement in one loop affect whether or not other loops are excuted?


    By doing a bunch of machine level crap behind the scenes, just the same
    way that everything in a high-level language does everything.


    > Are you saying, if I have:
    >
    > my @animals = qw(cat dog dino);
    >
    > for my $animal (@animals) {
    > last if $animal eq 'dog';
    > }
    >
    > for my $animal (@animals) {
    > print uc $animal, "\n";
    > }
    >
    > The second loop will not be excuted due to the 'last' statement in the
    > first loop.


    No, I'm pretty sure that is not what he is saying.

    More like

    for my $animal (@animals) {
    last if $animal eq 'dog';
    print $animal;
    };

    Would print 'dog', but not anything in @animals after 'dog'.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Jan 30, 2005
    #8
  9. > One thing from C that'd be really useful is to do away with the required
    > braces in one-line if/then/else blocks, like this:
    >
    > if ($foo)
    > func1($foo);
    > elsif ($bar)
    > func2($bar, $z);
    > else
    > return;


    That is just prone to errors. What if you had to add some functionality into
    one of the blocks? You would have to add the braces and forgetting to add
    them is easy.

    > I don't know if somebody already suggested this for Perl 6, but I think
    > it'd be a nice improvement. That and a real switch statement. :)


    http://www.perl6.org/doc/design/apo/A04.html#rfc_022__control_flow__builtin_switch_statement

    /jUSSi
    Jussi Mononen, Jan 30, 2005
    #9
  10. gargoyle <> writes:
    > On 2005-01-29, Matija Papec <> wrote:
    >> I'm guessing, "last" was picked because it's short and it sounds good along
    >> with "next". Further, "break" could blur things for C people as his
    >> "continue" friend is already used for something else.

    >
    > One thing from C that'd be really useful is to do away with the required
    > braces in one-line if/then/else blocks, like this:
    >
    > if ($foo)
    > func1($foo);
    > elsif ($bar)
    > func2($bar, $z);
    > else
    > return;


    Please, no. One of the things I like best about Perl is that the
    braces are required; I find it far more consistent than requiring them
    only if there happens to be more than one statement.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 30, 2005
    #10
  11. Jeremy Morton

    Anno Siegel Guest

    <> wrote in comp.lang.perl.misc:
    > "A. Sinan Unur" <> wrote:
    > > "Jeremy Morton" <> wrote


    [...]

    > > > 'last' makes it sound like the current loop will be the last,

    ^^^^
    s/loop/iteration/

    > > Your terminology is odd. How can the current loop be the last?

    >
    > By not executing another time.
    >
    > > How could
    > > a statement in one loop affect whether or not other loops are excuted?

    >
    > By doing a bunch of machine level crap behind the scenes, just the same
    > way that everything in a high-level language does everything.


    The OP failed to distinguish a loop (the entire compound statement)
    from its iterations (each pass through the body). That made the
    meaning less than clear.

    Anno
    Anno Siegel, Jan 30, 2005
    #11
  12. Jeremy Morton

    Matija Papec Guest

    X-Ftn-To: Jeremy Morton

    "Jeremy Morton" <> wrote:
    >>> immediately, whereas break makes it sound like the latter.

    >>
    >> I'm guessing, "last" was picked because it's short and it sounds good
    >> along with "next".

    >
    >That's a good reason to choose a keyword, because it 'sounds good'? Heh.
    >It doesn't make semantic sense, and that's far more important IMHO.


    Perhaps I'm too long with this language but "last" makes good semantic
    sense; this is from perldoc

    last The "last" command is like the "break" statement in C (as used
    in loops); it immediately exits the loop in question...

    LINE: while (<STDIN>) {
    last LINE if /^$/; # exit when done with header
    #...
    }

    You can think of it as "current element is the last one"

    >> Further, "break" could blur things for C people as
    >> his "continue" friend is already used for something else.

    >
    >Yes, I don't quite understand why 'continue' is used the way it is,
    >either... that doesn't make much sense. However i'd still rather have
    >'break' meaning what it does in most other languages i've come across. You


    I know this feeling but it isn't nearly frustrating as missing some language
    feature (hint: perl like array/hash slices, or anonymous functions in say,
    php? :))



    --
    Matija
    Matija Papec, Jan 30, 2005
    #12
  13. Jeremy Morton

    Matija Papec Guest

    X-Ftn-To: gargoyle

    gargoyle <> wrote:
    >One thing from C that'd be really useful is to do away with the required
    >braces in one-line if/then/else blocks, like this:
    >
    >if ($foo)
    > func1($foo);
    >elsif ($bar)
    > func2($bar, $z);
    >else
    > return;
    >
    >I don't know if somebody already suggested this for Perl 6, but I think
    >it'd be a nice improvement. That and a real switch statement. :)


    afaik, you're very close as switch statement should go in perl6 core, but
    for conditions they will lose only _round_ braces. ;)


    --
    Matija
    Matija Papec, Jan 30, 2005
    #13
  14. Jeremy Morton

    Matija Papec Guest

    X-Ftn-To: Abigail

    Abigail <> wrote:
    >;; with "next". Further, "break" could blur things for C people as his
    >;; "continue" friend is already used for something else.
    >
    >One of the reasons why the three loop control constructs are named
    >'last', 'redo' and 'next' is that they are all the same length.
    >
    >One of the reasons 'last' isn't called 'break' is that 'last' isn't
    >the same as 'break'. 'break' breaks the current loop - while 'last'
    >takes an optional argument, indicating the top level loop that will
    >be exited.


    Yes, but why should perl break behave completely same as C break?
    Such way of thinking isn't applied to || and && operators which behave as in
    C but are somehow extended in their behavior. :)



    --
    Matija
    Matija Papec, Jan 30, 2005
    #14
  15. Jeremy Morton

    Joe Smith Guest

    gargoyle wrote:

    > One thing from C that'd be really useful is to do away with the required
    > braces in one-line if/then/else blocks, like this:


    One thing that is good about Perl is that it does not have
    the ambiguity of braceless one-line then/else blocks.
    I would not want to see that change.
    -Joe
    Joe Smith, Jan 30, 2005
    #15
  16. Jeremy Morton

    gargoyle Guest

    On 2005-01-30, Jussi Mononen <> wrote:
    > That is just prone to errors. What if you had to add some functionality into
    > one of the blocks? You would have to add the braces and forgetting to add
    > them is easy.


    Then throw compiler error, if it sees more than one statement w/o
    braces.

    Some people don't like the way C does it, but some do. And Perl is
    about choices.

    Otherwise a similar argument could be used against this:

    if ( substr($foo, 0, 4) == BAR & BAZ and $xyz ^ x0ffff > $abc ) {
    launch_missiles();
    }

    What happens if you make a change here that affect operator precedence?
    It means you can screw up. But Perl allows it. Perl respect my free
    will to code how I want. And that's why I respect Perl. :)

    Let people read perlstyle man page and make their decision. If you want
    anal-rententive language, try python maybe.
    gargoyle, Jan 30, 2005
    #16
  17. "gargoyle" <> kirjoitti
    viestissä:lY8Ld.3401$...
    >> That is just prone to errors. What if you had to add some functionality
    >> into
    >> one of the blocks? You would have to add the braces and forgetting to add
    >> them is easy.

    >
    > Then throw compiler error, if it sees more than one statement w/o
    > braces.


    That's just what Perl does if you don't use braces with if-statement :-D

    You want to change Perl syntax to suit your personal preferences, although
    by definition the if-statement executes a {block} of code and needs braces
    because of that.

    How would the compiler know what you meant if you are not using
    else-statements?

    if( $hungry )
    eat();
    drink();

    if( $hungry ){
    eat();
    drink();
    }

    > Otherwise a similar argument could be used against this:
    >
    > if ( substr($foo, 0, 4) == BAR & BAZ and $xyz ^ x0ffff > $abc ) {
    > launch_missiles();
    > }
    >
    > What happens if you make a change here that affect operator precedence?
    > It means you can screw up. But Perl allows it. Perl respect my free
    > will to code how I want. And that's why I respect Perl. :)


    That is not related to syntax, it is just a logical error. You can code as
    many logical errors as you wish into the if-clause, within the syntax of
    course. If you force certain rules on syntax, you can prevent some logical
    errors caused by vague syntax.

    > Let people read perlstyle man page and make their decision. If you want
    > anal-rententive language, try python maybe.


    Preventing logical errors with syntax is not a style-issue, me thinks :)
    All this is IMO of course

    /jUSSi

    ps. I love C and earn my living with it and Perl.
    Jussi Mononen, Jan 30, 2005
    #17
  18. Jeremy Morton

    Anno Siegel Guest

    gargoyle <> wrote in comp.lang.perl.misc:
    > On 2005-01-30, Jussi Mononen <> wrote:
    > > That is just prone to errors. What if you had to add some functionality into
    > > one of the blocks? You would have to add the braces and forgetting to add
    > > them is easy.

    >
    > Then throw compiler error, if it sees more than one statement w/o
    > braces.


    You can't throw an error -- it is perfectly legit to have an unconditional
    statement after a conditional one.

    > Some people don't like the way C does it, but some do. And Perl is
    > about choices.


    Not about bad choices. The real problem with brace-less statements under
    "if" is an different one. It happens with nested "if"s and a following
    "else":

    if ( $alive ) if ( $well ) get_up() else stay_put();

    is essentially ambiguous. You can't indicate if "else" is an alternative
    to the first condition:

    if ( $alive ) {
    if ( $well ) {
    get_up();
    }
    } else {
    stay_put();
    }

    or to the second one:

    if ( $alive ) {
    if ( $well ) {
    get_up();
    } else {
    stay_put();
    }
    }

    It makes a difference, and the ambiguity can only be resolved "by force",
    there is no "natural" resolution. With braces, there can't be any doubt.

    Early compiler designs (Pascal, C, Algol) tended to ignore this ambiguity.
    Later ones (Modula2, Perl, not sure about Algol68) decided to enforce
    delimiters for this very reason. That was progress, there's no reason
    to go back behind it.

    Anno
    Anno Siegel, Jan 30, 2005
    #18
  19. Jeremy Morton

    Anno Siegel Guest

    gargoyle <> wrote in comp.lang.perl.misc:
    > On 2005-01-30, Jussi Mononen <> wrote:
    > > That is just prone to errors. What if you had to add some functionality into
    > > one of the blocks? You would have to add the braces and forgetting to add
    > > them is easy.

    >
    > Then throw compiler error, if it sees more than one statement w/o
    > braces.


    You can't throw an error -- it is perfectly legit to have an unconditional
    statement after a conditional one.

    > Some people don't like the way C does it, but some do. And Perl is
    > about choices.


    Not about bad choices. The real problem with brace-less statements under
    "if" is an different one. It happens with nested "if"s and a following
    "else":

    if ( $alive ) if ( $well ) get_up() else stay_put();

    is essentially ambiguous. You can't indicate whether "else" is an alternative
    to the first condition:

    if ( $alive ) {
    if ( $well ) {
    get_up();
    }
    } else {
    stay_put();
    }

    or to the second one:

    if ( $alive ) {
    if ( $well ) {
    get_up();
    } else {
    stay_put();
    }
    }

    It makes a difference, and the ambiguity can only be resolved "by force",
    there is no "natural" resolution. With braces, there can't be any doubt.

    Early compiler designs (Pascal, C, Algol) tended to ignore this ambiguity.
    Later ones (Modula2, Perl, not sure about Algol68) decided to enforce
    delimiters for this very reason. That was progress, there's no reason
    to go back behind it.

    Anno
    Anno Siegel, Jan 30, 2005
    #19
  20. "Abigail" <> wrote in message
    news:...
    > Matija Papec () wrote on MMMMCLXIX September MCMXCIII
    > in <URL:news:>:
    > ;; X-Ftn-To: Jeremy Morton
    > ;;
    > ;; "Jeremy Morton" <> wrote:
    > ;; >Probably been mentioned before but I fail to see why Perl changed the
    > ;; >'break' keyword to 'last', in loops. Bear with me on this - it seems
    > ;; >semantically more accurate to say 'break' - you're immediately
    > breaking out
    > ;; >of the loop. 'last' makes it sound like the current loop will be the
    > last,
    > ;; >but not that the execution should be stopped immediately, whereas
    > break
    > ;; >makes it sound like the latter.
    > ;;
    > ;; I'm guessing, "last" was picked because it's short and it sounds good
    > along
    > ;; with "next". Further, "break" could blur things for C people as his
    > ;; "continue" friend is already used for something else.
    >
    >
    > One of the reasons why the three loop control constructs are named
    > 'last', 'redo' and 'next' is that they are all the same length.
    >
    > One of the reasons 'last' isn't called 'break' is that 'last' isn't
    > the same as 'break'. 'break' breaks the current loop - while 'last'
    > takes an optional argument, indicating the top level loop that will
    > be exited.


    Hang on, are you saying 'break' has a meaning in Perl? I didn't think it
    was reserved.

    In addition, i'm not sure what you're getting at re: 'last' taking an
    argument. 'break' could just as easily take an optional argument and mean
    the same thing.


    --
    Best regards,
    Jeremy Morton (Jez)
    Jeremy Morton, Jan 30, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeremy Morton

    Perl loops should use break, not last

    Jeremy Morton, Jan 29, 2005, in forum: Perl
    Replies:
    1
    Views:
    5,137
    Big and Blue
    Jan 30, 2005
  2. viza

    break or continue out of nested loops

    viza, Jul 16, 2003, in forum: C Programming
    Replies:
    5
    Views:
    1,016
    sunil
    Jul 17, 2003
  3. Replies:
    12
    Views:
    955
  4. Talha Oktay
    Replies:
    3
    Views:
    175
    Simon Kröger
    Mar 30, 2006
  5. Me
    Replies:
    2
    Views:
    241
Loading...

Share This Page