if for...

Discussion in 'Perl Misc' started by Robert Wallace, Feb 11, 2004.

  1. I can:
    print "hello" if (m/world/);
    I can:
    $x = 300 if ($ == 10);

    why can't I:
    foreach (@arr) if (m/str/) {
    ....}

    or

    foreach (@arr) {
    ....
    } if (m/str/)
    ????????
     
    Robert Wallace, Feb 11, 2004
    #1
    1. Advertising

  2. Robert Wallace

    Uri Guttman Guest

    >>>>> "RW" == Robert Wallace <> writes:

    RW> I can:
    RW> print "hello" if (m/world/);
    RW> I can:
    RW> $x = 300 if ($ == 10);

    RW> why can't I:
    RW> foreach (@arr) if (m/str/) {
    RW> ...}

    RW> or

    RW> foreach (@arr) {
    RW> ...
    RW> } if (m/str/)
    RW> ????????

    because you can't. statement modifiers work only on plain statements,
    not blocks.

    uri

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
     
    Uri Guttman, Feb 11, 2004
    #2
    1. Advertising

  3. Uri Guttman wrote:
    >
    > >>>>> "RW" == Robert Wallace <> writes:

    >

    ....

    > RW> why can't I:
    > RW> foreach (@arr) if (m/str/) {
    > RW> ...}
    >
    > RW> or
    >
    > RW> foreach (@arr) {
    > RW> ...
    > RW> } if (m/str/)
    > RW> ????????
    >
    > because you can't. statement modifiers work only on plain statements,
    > not blocks.
    >



    well, I like to pretty up lines like:

    if ($a == $b) {
    foreach (@arr1) {
    if (m/item/) {
    ...
    ...
    elsif ...
    }
    }

    or should I leave these such lines alone?
     
    Robert Wallace, Feb 11, 2004
    #3
  4. Robert Wallace

    Uri Guttman Guest

    >>>>> "RW" == Robert Wallace <> writes:


    RW> well, I like to pretty up lines like:

    RW> if ($a == $b) {
    RW> foreach (@arr1) {
    RW> if (m/item/) {
    RW> ...
    RW> ...
    RW> elsif ...
    RW> }
    RW> }

    RW> or should I leave these such lines alone?

    pretty up what? i see nothing there that looks clumsy or needs to be
    changed. putting an if modifier at the end of that for block would be
    very hard to read.

    uri

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
     
    Uri Guttman, Feb 11, 2004
    #4
  5. Robert Wallace

    Tore Aursand Guest

    On Wed, 11 Feb 2004 16:28:39 -0500, Robert Wallace wrote:
    > why can't I:
    > foreach (@arr) if (m/str/) {
    > ...}
    >
    > or
    >
    > foreach (@arr) {
    > ...
    > } if (m/str/)
    > ????????


    Because it's a pain in the ass to read? :) This is easier to read, thus
    easier to maintain;

    if ( m/str/ ) {
    foreach ( @arr ) {
    }
    }


    --
    Tore Aursand <>
    "Omit needless words. Vigorous writing is concise. A sentence should
    contain no unnecessary words, a paragraph no unnecessary sentences,
    for the same reason that a drawing should have no unnecessary lines
    and a machine no unnecessary parts." -- William Strunk Jr.
     
    Tore Aursand, Feb 11, 2004
    #5
  6. On Wed, 11 Feb 2004 16:41:33 -0500, Robert Wallace <>
    wrote:

    >well, I like to pretty up lines like:
    >
    >if ($a == $b) {
    > foreach (@arr1) {
    > if (m/item/) {
    > ...
    > ...
    > elsif ...
    > }
    >}
    >
    >or should I leave these such lines alone?


    There are probably many "better" ways to do it. What about reading
    something about next, last, et similia?


    Michele
    --
    you'll see that it shouldn't be so. AND, the writting as usuall is
    fantastic incompetent. To illustrate, i quote:
    - Xah Lee trolling on clpmisc,
    "perl bug File::Basename and Perl's nature"
     
    Michele Dondi, Feb 11, 2004
    #6
  7. On Wed, 11 Feb 2004 16:28:39 -0500, Robert Wallace <>
    wrote:

    >I can:
    >print "hello" if (m/world/);


    OK

    >I can:
    >$x = 300 if ($ == 10);


    Well, this perfectly valid, but I bet you were not thinking of $= =
    10, were you?

    >why can't I:
    >foreach (@arr) if (m/str/) {


    for (@arr) {
    whatever() if /str/;
    }

    /str/ and whatever() for @arr;

    etc.


    Michele
    --
    you'll see that it shouldn't be so. AND, the writting as usuall is
    fantastic incompetent. To illustrate, i quote:
    - Xah Lee trolling on clpmisc,
    "perl bug File::Basename and Perl's nature"
     
    Michele Dondi, Feb 11, 2004
    #7
  8. Robert Wallace

    Ben Morrow Guest

    Michele Dondi <> wrote:
    > On Wed, 11 Feb 2004 16:28:39 -0500, Robert Wallace <>
    > wrote:
    >
    > >why can't I:
    > >foreach (@arr) if (m/str/) {

    >
    > for (@arr) {
    > whatever() if /str/;
    > }
    >
    > /str/ and whatever() for @arr;


    Nonononono. You want to test the condition outside the loop, not loop
    over every elt in the list only to do nothing.

    Ben

    --
    Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
    From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
    (Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
    /Alcestis/) [ flame, and falls out of sight. ]
     
    Ben Morrow, Feb 11, 2004
    #8
  9. Robert Wallace <> writes:

    > print "hello" if (m/world/);
    > I can:
    > $x = 300 if ($ == 10);
    >
    > why can't I:
    > foreach (@arr) if (m/str/) {
    > ...}


    I think you really meant to ask why can't I say:

    .... if m/str/ for @arr;

    Because you can't, so there! It has been decided and it ain't gonna
    change. Very many people (including myself) have said they want it
    but Larry Wall has put his foot down on this.

    Some people 'round 'ere (notably Uri) here claim that there are real
    technical reasons to be found in the p5p mailing list archives. I've
    looked and I can't find them.

    All I can find are:

    [1] Because you can't, so there!
    [2] Because you could abuse it to produce unreadable code
    [3] Because using for without an explicit loop variable is bad
    [4] For well known reasons I won't repeat

    You'll note that [1] and [4] are no sort of explaintion. [2] applies
    to pretty much everyting in Perl. [3] is an argument against the
    "for" statement modifier per-se, not an argument against being able to
    chain statement modifiers.

    --
    \\ ( )
    . _\\__[oo
    .__/ \\ /\@
    . l___\\
    # ll l\\
    ###LL LL\\
     
    Brian McCauley, Feb 12, 2004
    #9
  10. Robert Wallace

    Bart Lateur Guest

    Robert Wallace wrote:

    >why can't I:
    >foreach (@arr) if (m/str/) {
    >...}


    Try grep.

    foreach (grep m/str/, @arr) {
    ...}

    --
    Bart.
     
    Bart Lateur, Feb 12, 2004
    #10
  11. On Wed, 11 Feb 2004 22:18:30 +0000 (UTC), Ben Morrow
    <> wrote:

    >Michele Dondi <> wrote:
    >> On Wed, 11 Feb 2004 16:28:39 -0500, Robert Wallace <>
    >> wrote:
    >>
    >> >why can't I:
    >> >foreach (@arr) if (m/str/) {

    >>
    >> for (@arr) {
    >> whatever() if /str/;
    >> }
    >>
    >> /str/ and whatever() for @arr;

    >
    >Nonononono. You want to test the condition outside the loop, not loop
    >over every elt in the list only to do nothing.


    Ben, once again I stand corrected by you! Of course if the OP wants to
    test the condition outside of the loop, and after it, with a statement
    modifier, he may consider using a do block. But in most cases I can't
    see what he could gain by doing this in terms of readability.

    However the point is that the existing Perl flow control constructs
    and their syntax already provide a flexible tools to write quite
    readable code. I think we all agree on this...


    Michele


    Michele
    --
    you'll see that it shouldn't be so. AND, the writting as usuall is
    fantastic incompetent. To illustrate, i quote:
    - Xah Lee trolling on clpmisc,
    "perl bug File::Basename and Perl's nature"
     
    Michele Dondi, Feb 13, 2004
    #11
  12. Brian McCauley <> wrote:

    > I think you really meant to ask why can't I say:
    >
    > .... if m/str/ for @arr;

    [...]
    > All I can find are:
    >
    > [1] Because you can't, so there!
    > [2] Because you could abuse it to produce unreadable code
    > [3] Because using for without an explicit loop variable is bad
    > [4] For well known reasons I won't repeat
    >
    > You'll note that [1] and [4] are no sort of explaintion. [2] applies
    > to pretty much everyting in Perl. [3] is an argument against the
    > "for" statement modifier per-se, not an argument against being able to
    > chain statement modifiers.


    Ok, so here are some more:

    1. It brings up the arguments that happened in p6l over
    if/unless/for/foreach/while/until/map/grep/do
    2. Parser reasons
    3. postfix if is much less flexible than low-precedence logic anyway
    (and, or)

    Number 2 breaks down like this:

    If your grammar is generic, you want to be able to string:

    print if /\d/ for @{$_} for @stuff;

    but then you lose the ability to access the $_ from the outer loop. In
    this case, that's not too bad, but there are plenty of cases where you
    would want to.

    So, you have to restrict for to a single instance, and that seems
    non-intuitive to many users, so you really haven't gained much clarity
    in the language.
     
    Aaron Sherman, Feb 13, 2004
    #12
  13. (Aaron Sherman) writes:

    > Brian McCauley <> wrote:
    >
    > > I think you really meant to ask why can't I say:
    > >
    > > .... if m/str/ for @arr;

    > [...]
    > > All I can find are:
    > >
    > > [1] Because you can't, so there!
    > > [2] Because you could abuse it to produce unreadable code
    > > [3] Because using for without an explicit loop variable is bad
    > > [4] For well known reasons I won't repeat
    > >
    > > You'll note that [1] and [4] are no sort of explaintion. [2] applies
    > > to pretty much everyting in Perl. [3] is an argument against the
    > > "for" statement modifier per-se, not an argument against being able to
    > > chain statement modifiers.

    >
    > Ok, so here are some more:


    I'm not convinced that these are more.

    > 1. It brings up the arguments that happened in p6l over
    > if/unless/for/foreach/while/until/map/grep/do


    Isn't your [1] my [4]?

    > 2. Parser reasons


    Do you mean _real_ parser problems as in "it would be difficult to
    make the Perl parser cope"? People seem to claim these exist these
    exist but I've never seen anyone present hard facts. Whenever they
    are challenged to explain what they mean they end up falling back on
    my [2,3].

    > 3. postfix if is much less flexible than low-precedence logic anyway
    > (and, or)


    This is true, but it is often more readable. Being able to choose a
    more readable way to say something is good.

    > Number 2 breaks down like this:
    >
    > If your grammar is generic, you want to be able to string:
    >
    > print if /\d/ for @{$_} for @stuff;


    Yes I do often want to do things like that because it is clear and
    concise. At the moment I usually write the above as:

    print for grep { /\d/ } map { @$_ } @stuff;

    This is just as clear, almost as concise, but more memory hungy.

    > but then you lose the ability to access the $_ from the outer loop.


    That is not a _real_ parser problem. Perl would have no problem
    knowing which $_ was in scope at any point. If the code them
    complicated enough the programmer could loose track, but them

    > In this case, that's not too bad, but there are plenty of cases
    > where you would want to.


    So, like I said above, whenever people put forward your [2] usually
    when they try to explain it fall back on some varient of my [2,3] as
    you have done.

    You'll also note the fact that chaining or nesting multiple map and
    grep within a single expression there are also multiple different $_
    and you can only ever get at the innermost one at any point. The
    problem that you say would be introduced by allowing multiple for
    postfix already exists. If this ever becomes an issue I usually stop
    trying to do the whole lot in one statement.

    > So, you have to restrict for to a single instance,


    No you don't.

    > and that seems non-intuitive to many users


    So don't do it.

    --
    \\ ( )
    . _\\__[oo
    .__/ \\ /\@
    . l___\\
    # ll l\\
    ###LL LL\\
     
    Brian McCauley, Feb 13, 2004
    #13
  14. Aaron Sherman wrote:
    >
    > Brian McCauley <> wrote:
    >
    > > I think you really meant to ask why can't I say:
    > >
    > > .... if m/str/ for @arr;

    > [...]
    > > All I can find are:
    > >

    ........

    > >
    > > You'll note that [1] and [4] are no sort of explaintion. [2] applies
    > > to pretty much everyting in Perl. [3] is an argument against the
    > > "for" statement modifier per-se, not an argument against being able to
    > > chain statement modifiers.

    >
    > Ok, so here are some more:

    ...........
    > So, you have to restrict for to a single instance, and that seems
    > non-intuitive to many users, so you really haven't gained much clarity
    > in the language.




    wow, you guys paint such a dark picture.
     
    Robert Wallace, Feb 13, 2004
    #14
  15. Brian McCauley <> wrote

    > > So, you have to restrict for to a single instance,

    >
    > No you don't.
    >
    > > and that seems non-intuitive to many users

    >
    > So don't do it.


    So, what this really comes down to is this: people have stated their
    reasons for disagreeing with this idea (as I have) and you disagree
    back. That's fine, but don't discount such disagreement. I don't think
    you've added anything new to the debate, and honestly, it's just
    syntatic sugar that can be re-stated trivially. I think postfix loops
    were a mistake. Postfix logic was a lesser mistake, but one I can live
    with, but postfix loops just force too many people to think about a
    statement in a way that Perl doesn't on the whole.

    And for the record, the p6l discussion is wide open to the public in
    the archives. It raged on for a month or more, so I don't think you'll
    have any trouble finding it. I feel such footnotes to well archived
    information are better than re-posting several megabytes of heated
    conversation.... You can find it by searching for "elsunless" ...
    postfix operations, continue blocks, scoping and switch-like uses of
    if/elsif/else were discussed ad nauseum.
     
    Aaron Sherman, Feb 16, 2004
    #15
  16. Robert Wallace <> wrote

    > > So, you have to restrict for to a single instance, and that seems
    > > non-intuitive to many users, so you really haven't gained much clarity
    > > in the language.

    >
    > wow, you guys paint such a dark picture.


    It's not really that dark, it's just that Perl has at its core a way
    of expressing programms a bit more like the way humans think than
    other languages. To tweak the language you must first think about the
    impact on that relationship.

    I think that chaining postfix operations would "sound" a bit better,
    but ultimatey because of the complicated scope issues an difficulty
    editing any such chain it would lead to a less "thinkable" statement.

    Here's an example:

    print if /\d/ for @{$_} for keys %{$_} for @_;

    Ok, now just make a small change... make the innermost conditional
    match if $_ is a reference and is equal to the outermost reference....

    I'd write it as:

    for my $hashref (@_) {
    for my $arrref (grep {(ref($_) && $_ eq $hashref) || /\d/} keys
    %{$hsahref}) {
    print;
    }
    }

    But you can't use that grep very effectively inside the chained
    postfix operations.

    And is the above so hard to write?
     
    Aaron Sherman, Feb 16, 2004
    #16
  17. (Aaron Sherman) writes:

    > Brian McCauley <> wrote
    >
    > > > So, you have to restrict for to a single instance,

    > >
    > > No you don't.
    > >
    > > > and that seems non-intuitive to many users

    > >
    > > So don't do it.

    >
    > So, what this really comes down to is this: people have stated their
    > reasons for disagreeing with this idea (as I have) and you disagree
    > back. That's fine, but don't discount such disagreement.


    I don't "discount disagreement". I simply assert that you have drawn
    an invalid logical inference in your statement "so, you have to...".
    If your statement "so, you have to..." was not intended to imply that
    you thought you were drawing a logical inference then I'm sorry.

    > I don't think you've added anything new to the debate,


    If you look back at this thread you'll find I did not attempt to add
    anything new to the debate. I attempted to summarise it for the OP.
    You then tried to add something my summary. I tried to explain how
    you had not added anything. You came back and said that _I_ hadn't
    added anything.

    > I think postfix loops were a mistake.


    I have no problem with that view. I do not discount it. What I
    object to stongly is people who assert that there's some hard factual
    something wrong with _nested_ postfix loops as distinct from there
    being something wrong with postfix loops per se.

    > And for the record, the p6l discussion is wide open to the public in
    > the archives. It raged on for a month or more, so I don't think you'll
    > have any trouble finding it.


    As I have stated I have found several instansiations.

    > I feel such footnotes to well archived
    > information are better than re-posting several megabytes of heated
    > conversation....


    In general I agree completely. But now we've got to state
    where the vast majority of the discussion that can be found by doing a
    search of the archives consists of people saying "don't discuss this
    again, search the archives".

    > You can find it by searching for "elsunless" ...
    > postfix operations, continue blocks, scoping and switch-like uses of
    > if/elsif/else were discussed ad nauseum.


    I can find only one sizable thread in p6l containing the world
    "elsunless" and that was:

    http://groups.google.com/groups?threadm=

    Can you confirm that that was the one?

    I've only skimmed over it so far but I can't really see how it applies
    to Perl5.

    --
    \\ ( )
    . _\\__[oo
    .__/ \\ /\@
    . l___\\
    # ll l\\
    ###LL LL\\
     
    Brian McCauley, Feb 17, 2004
    #17
    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.

Share This Page