Simple question on documentation of the foreach command

[Bruce Horrocks]

Under ActivePerl 5.8.0, I can find no mention of the

print "Hello world" foreach (1..5);

version / syntax of the foreach command.

Have I missed it or is it missing?

 

[Walter Roberson]

:Under ActivePerl 5.8.0, I can find no mention of the

: print "Hello world" foreach (1..5);

:version / syntax of the foreach command.

:Have I missed it or is it missing?

Try looking at man perlsyn:

Any simple statement may optionally be followed by a SINGLE modifier,
just before the terminating semicolon (or block ending). The possible
modifiers are:

if EXPR
unless EXPR
while EXPR
until EXPR
foreach EXPR

 

[Ben Morrow]

As it's already been mentioned where to find the explanation, I would just
add that a "for" would look nicer in this case:

s/this/every/ (IMHO)

Ben

 

[Matt Garrish]

Under ActivePerl 5.8.0, I can find no mention of the

print "Hello world" foreach (1..5);

version / syntax of the foreach command.

As it's already been mentioned where to find the explanation, I would just
add that a "for" would look nicer in this case:

print 'Hello world' for (1..5);

Matt

 

[Brian McCauley]

:Under ActivePerl 5.8.0, I can find no mention of the

: print "Hello world" foreach (1..5);

:version / syntax of the foreach command.

:Have I missed it or is it missing?

Try looking at man perlsyn:

Any simple statement may optionally be followed by a SINGLE modifier,
just before the terminating semicolon (or block ending).

Is there any real reason for that 'SINGLE' ?

Note: by "real reason" I exclude reasons relating to aesthetics (the
human-readability of code). The language syntax has no buisness
arbitrarily preventing you nesting syntactical constucts for purely
aesthetic reasons.

I am forever wanting to write:

EXPR if COND for LIST;

I think this is much nicer than:

for ( LIST ) { EXPR if COND }

And often more natural than:

EXPR for grep COND, LIST;

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Juha Laiho]

Under ActivePerl 5.8.0, I can find no mention of the

print "Hello world" foreach (1..5);

And in case it was the "1..5" part that you were wondering, it's
documented in "perldoc perlop" page, in chapter "Range operators".

 

[Uri Guttman]

BM> Is there any real reason for that 'SINGLE' ?

BM> Note: by "real reason" I exclude reasons relating to aesthetics (the
BM> human-readability of code). The language syntax has no buisness
BM> arbitrarily preventing you nesting syntactical constucts for purely
BM> aesthetic reasons.

yes, larry said he won't do it in perl5 and in perl6.

BM> I am forever wanting to write:

BM> EXPR if COND for LIST;

and what about EXPR while <> for EXPR?

what is $_ set too?

there are serious semantic and even syntactic issues with multiple
statement modifiers. search the perl6 language list for threads on that
(in the last month or two IIRC). larry covers some good reasons and he
says NO!

uri

 

[Anno Siegel]

Is there any real reason for that 'SINGLE' ?

Note: by "real reason" I exclude reasons relating to aesthetics (the
human-readability of code). The language syntax has no buisness
arbitrarily preventing you nesting syntactical constucts for purely
aesthetic reasons.

It has happened before, see the outlawed "my $x; local $x". As a
post-modern language, Perl can do things that would otherwise be
considered arbitrary, or even fascist. Take it or leave it

I mostly agree with the restriction. Nested statement modifiers have
ways of becoming unreadable. It would take time and experimentation
to come up with perhaps only few usable cases.

I am forever wanting to write:

EXPR if COND for LIST;

It does come naturally, doesn't it? Every so often I have to re-write
the above as

COND and EXPR for LIST;

I find that an acceptable alternative. Well, most of the time it works.

[more alternatives]

Anno

 

[Randal L. Schwartz]

Brian> Is there any real reason for that 'SINGLE' ?

Larry said so. And I agree with him. He's seen the hell that BASIC+
coding became when those were allowed to be stacked (and so did I).
You thought Perl readability was tough already?

Brian> Note: by "real reason" I exclude reasons relating to aesthetics (the
Brian> human-readability of code). The language syntax has no buisness
Brian> arbitrarily preventing you nesting syntactical constucts for purely
Brian> aesthetic reasons.

Yes it does. The P in Perl stands for Practical. This is not CS101.
"That makes it orthogonal" will never win points in Larry's school
of practical Perl design.

print "Just another Perl hacker,"

 

[Ben Morrow]

Yes it does. The P in Perl stands for Practical.

I thought it sttod for 'Pathologicaly'?

Ben

 

[Randal L. Schwartz]

Ben> I thought it sttod for 'Pathologicaly'?

Then this is an example of a pathological case.

print "Just another Perl hacker,";

 

[Brian McCauley]

BM> Is there any real reason for that 'SINGLE' ?

BM> Note: by "real reason" I exclude reasons relating to aesthetics (the
BM> human-readability of code). The language syntax has no buisness
BM> arbitrarily preventing you nesting syntactical constucts for purely
BM> aesthetic reasons.

yes,

What are you saying "yes" to? Are you agreeing that it is wrong that
the language arbitrarily disallows nested modifiers or are you saying
yes, there is a real real reason for disallowing them.

larry said he won't do it in perl5 and in perl6.

But AFAIK his reasons wrt Perl5 were in the class I explicitly
excluded from the class "real reason".

BM> I am forever wanting to write:

BM> EXPR if COND for LIST;

and what about EXPR while <> for EXPR?

what is $_ set too?

Er, exactly the same as it would be in:

for ( EXPR ) {
while ( <> ) {
EXPR;
}
}

there are serious semantic and even syntactic issues with multiple
statement modifiers. search the perl6 language list for threads on that
(in the last month or two IIRC). larry covers some good reasons and he
says NO!

OK, I'm not a follower of the Perl6 discussions. But looking there
just now, as far as I can see all the "reasons" given are excuses to
justifty a decision that was taken on aesthetic grounds.

There are no real syntactic ambiguities, and those semantic issues
that exist with multiple modifiers apply equally when using block
syntax.

If Larry wants to put his foot down and say "no nested statement
modifiers because I think they are ugly" he can do so. But if his
only reason is his own aesthetics then people shouldn't pretend
otherwise. (I say "people" because I don't actually see any evidence
of Larry pretending otherwise).

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Uri Guttman]

BM> Note: by "real reason" I exclude reasons relating to aesthetics (the
BM> human-readability of code). The language syntax has no buisness
BM> arbitrarily preventing you nesting syntactical constucts for purely
BM> aesthetic reasons.
BM> What are you saying "yes" to? Are you agreeing that it is wrong that
BM> the language arbitrarily disallows nested modifiers or are you saying
BM> yes, there is a real real reason for disallowing them.

i agree they should not be supported. my reasons (and i have wanted to
have them) include that it will make for more confusing code with little
benefit and aesthetics. and there are semantic issues.

BM> Er, exactly the same as it would be in:

BM> for ( EXPR ) {
BM> while ( <> ) {
BM> EXPR;
BM> }
BM> }

but you can use my vars in that for loop. you can't with modifiers. and
adding my to that would make it even worse. and i dislike using $_ in
general as i like named things for better documentation.

BM> There are no real syntactic ambiguities, and those semantic issues
BM> that exist with multiple modifiers apply equally when using block
BM> syntax.

BM> If Larry wants to put his foot down and say "no nested statement
BM> modifiers because I think they are ugly" he can do so. But if his
BM> only reason is his own aesthetics then people shouldn't pretend
BM> otherwise. (I say "people" because I don't actually see any evidence
BM> of Larry pretending otherwise).

just search for them and read larry's comments. he explains it better
than i could.

uri

 

[Brian McCauley]

I mostly agree with the restriction. Nested statement modifiers have
ways of becoming unreadable.

Oh, come on! Compared to s///e, code blocks in regex, and map, and ?:
and... I could go on for ages. There are lots of constructs you can
nest inappropriately and produce utterly incomprehensible code. I
simply cant see why this one case should be so different.

It would take time and experimentation to come up with perhaps only
few usable cases.

Er... I hit several a week in my work. Besides IIRC the constraint
actually makes the compiler more complex not less.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Sam Holden]

What are you saying "yes" to? Are you agreeing that it is wrong that
the language arbitrarily disallows nested modifiers or are you saying
yes, there is a real real reason for disallowing them.

There was only one question in that quoted text, so there can not be
ambiguity as to what it was answering.

 

[Bruce Horrocks]

And in case it was the "1..5" part that you were wondering, it's
documented in "perldoc perlop" page, in chapter "Range operators".

No it was the foreach following the statement rather than the number of
loops that I was interested in.

Thanks for all the quick answers and the interesting side discussion on
single.

So, it is documented, but not under the foreach / for sections of
persyn, which is where I would expect it to be.

Regards,

 

[Tad McClellan]

No it was the foreach following the statement

So, it is documented, but not under the foreach / for sections of

and the while section, and the if section, and the unless section...

 

[Bruce Horrocks]

and the while section, and the if section, and the unless section...

Eh?

If I see a piece of code that uses "foreach" in a way that is new to me,
and I wished to look it up in order to understand it better, why would I
look under "while", "if" or "unless" as you are suggesting here?

Regards,

 

[Tad McClellan]

Eh?

If I see a piece of code that uses "foreach" in a way that is new to me,
and I wished to look it up in order to understand it better, why would I
look under "while", "if" or "unless" as you are suggesting here?

I am not suggesting that here.

If the modifier form of for() is documented in the section on for(),
then it should also be documented 4 other times for the 4 other
places where it can be used.

The modifier form is not specific to for(), so the section on for()
isn't the best place to document it.

 

[Ben Morrow]

If the modifier form of for() is documented in the section on for(),
then it should also be documented 4 other times for the 4 other
places where it can be used.

The modifier form is not specific to for(), so the section on for()
isn't the best place to document it.

A note to the effect 'see also "Statement Modifiers" in perlsyn'
wouldn't go amiss, though.

Ben