if for...

R

Robert Wallace

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/)
????????
 
U

Uri Guttman

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
 
R

Robert Wallace

Uri said:
....

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?
 
U

Uri Guttman

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
 
T

Tore Aursand

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 <[email protected]>
"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.
 
M

Michele Dondi

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
 
M

Michele Dondi

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
 
B

Ben Morrow

Michele Dondi said:
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
 
B

Brian McCauley

Robert Wallace said:
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\\
 
M

Michele Dondi

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
 
A

Aaron Sherman

Brian McCauley said:
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.
 
B

Brian McCauley

Brian McCauley said:
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\\
 
R

Robert Wallace

Aaron said:
Brian McCauley said:
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.
 
A

Aaron Sherman

Brian McCauley said:
No you don't.


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.
 
A

Aaron Sherman

Robert Wallace said:
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?
 
B

Brian McCauley

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/[email protected]

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\\
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top