Simple question on documentation of the foreach command

[Anno Siegel]

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.

There are dialects of Basic that allow nested modifiers. Nested loops
are an horror written that way.

Er... I hit several a week in my work.

The only combinations I would really like to use are combinations of
postfix "if" with the others. That are four:

EXPR if COND while COND
EXPR while COND if COND
STATEMENT if COND for LIST
EXPR for LIST if COND

Okay, eight if you count "unless" too.

The combination with "if" is the least problematic because "if"
doesn't do things to $_.

actually makes the compiler more complex not less.

If compiler complexity were a criterion, Perl would belong on the
dung heap

....oh, and while I'm wishing, i also want

map EXPR while COND

Anno
Anno

 

[Anno Siegel]

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.

There are dialects of Basic that allow nested modifiers. Nested loops
are a horror written that way.

Er... I hit several a week in my work.

The only combinations I would really like to use are combinations of
postfix "if" with the others. That are four:

EXPR if COND while COND
EXPR while COND if COND
STATEMENT if COND for LIST
EXPR for LIST if COND

Okay, eight if you count "unless" too.

The combination with "if" is the least problematic because "if"
doesn't do things to $_.

actually makes the compiler more complex not less.

If compiler complexity were a criterion, Perl would belong on the
dung heap

....oh, and while I'm wishing, i also want

map EXPR while COND

Anno

 

[Uri Guttman]

AS> ...oh, and while I'm wishing, i also want

AS> map EXPR while COND

that makes little sense as map returns a list. (quiet abigail). it is
still ugly if converted to a for loop. and it can be done as:

my @results = map { COND ? EXPR : () } @INPUT

your line doesn't even have the input. and actually it makes even less
sense then:

map EXPR, @input while COND

do you want the input processed once or as long as COND is true? that is
legal syntax but damned if it will do what i want without @input as a
gating factor.

uri

 

[Anno Siegel]

AS> ...oh, and while I'm wishing, i also want

AS> map EXPR while COND

that makes little sense as map returns a list. (quiet abigail). it is

That's the idea. "Collect the values of EXPR as long as COND is true".
To be explicit:

do {
my @coll;
push @coll, EXPR while COND;
@coll;
}

"map ... while ..." would save you the collective variable.

still ugly if converted to a for loop. and it can be done as:

my @results = map { COND ? EXPR : () } @INPUT

Not what I mean.

your line doesn't even have the input.

That's what while does, looping without an input list. "map" is there
so it collects the results (or counts them, in scalar context) .

and actually it makes even less
sense then:

map EXPR, @input while COND

Entirely not what I mean.

do you want the input processed once or as long as COND is true? that is

legal syntax but damned if it will do what i want without @input as a
gating factor.

Other while loops run without that safety net. Sure, COND or EXPR must
have a side effect, or you loop indefinitely. But that's so with all
while loops.

Anno

 

[Bruce Horrocks]

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.

ISWYM now. Yes, I agree, that to be consistent then the equivalent
change needs to be made for the other cases as well. Ben's suggestion,
in another post, of a "see also..." is short and sweet and would do the
job.

I shall start on the process of understanding how suggestions for
improvements to the docs are made and try to put it through.

Regards,

 

[Tad McClellan]

In message <[email protected]>, Tad McClellan

Ben's suggestion,
in another post, of a "see also..." is short and sweet and would do the
job.

Yes it would.

I shall start on the process of understanding how suggestions for
improvements to the docs are made

With great difficulty.

and try to put it through.

The docs are part of Perl. A bug in the docs is a bug in Perl, so:

perldoc perlbug


It has a much better chance of being incorporated if the bug
report has a diff for the suggested change.