print array with separator?
in [Perl]
|
Prev: LibXML (XPATH) and escape
Next: Module name access
From: Jochen Lehmeier on 27 Jan 2010 03:40 On Wed, 27 Jan 2010 02:42:47 +0100, Ben Morrow <ben(a)morrow.me.uk> wrote: > $_ ought to be an alias to a constant. From "perldoc map": "Note that $_ is an alias to the list value, so it can be used to modify the elements of the LIST. While this is useful and supported, it can cause bizarre results if the elements of LIST are not variables. Using a regular foreach loop for this purpose would be clearer in most cases." From "perldoc grep": "Note that $_ is an alias to the list value, so it can be used to modify the elements of the LIST. While this is useful and supported, it can cause bizarre results if the elements of LIST are not variables. Similarly, grep returns aliases into the original list, much as a for loop's index variable aliases the list elements. That is, modifying an element of a list returned by grep (for example, in a foreach , map or another grep) actually modifies the element in the original list. This is usually something to be avoided when writing clear code."
From: C.DeRykus on 27 Jan 2010 14:39 On Jan 25, 8:23 pm, "Uri Guttman" <u...(a)StemSystems.com> wrote: > >>>>> "JB" == John Bokma <j...(a)castleamber.com> writes: > > JB> I wouldn't use it though, but like Abigail, IIRC, once wrote, there is > JB> no reason to have a problem with map in void context because we use > JB> other functions in void context without problems (like print). > > the point with map in void context is not efficiency but in conveying > meaning to the reader. map is intended to generate a list, not execute > side effects. for modifier does the same thing and is meant for side > effects as it doesn't generate a list. perl has many related things like > this and you should choose the one with better semantics for your > intentions. map generates lists so use it that way. for modifier doesn't > generate lists so use it for side effects. > However 'perldoc -q void' has an addendum about map being context aware since 5.8.1. And there's no "ahem, but map is intended to generate a list" to disparage its use in void content. I prefer the for modifier but wish 'void' was a keyword for side- effects only map use. Then I suppose there'd be crazies who'd use void with print or delete too :). -- Charles DeRykus
From: J�rgen Exner on 27 Jan 2010 14:50 "C.DeRykus" <derykus(a)gmail.com> wrote: >I prefer the for modifier but wish 'void' was a keyword for side- >effects only map use. Doesn't undef = map ..... work (I didn't try it)? jue
From: Dr.Ruud on 27 Jan 2010 14:51 Jochen Lehmeier wrote: > From "perldoc grep": > > "Note that $_ is an alias to the list value, so it can be used to modify > the elements of the LIST. While this is useful and supported, it can > cause bizarre results if the elements of LIST are not variables. > Similarly, grep returns aliases into the original list, much as a for > loop's index variable aliases the list elements. That is, modifying an > element of a list returned by grep (for example, in a foreach , map or > another grep) actually modifies the element in the original list. This > is usually something to be avoided when writing clear code." Yeah, though I'd rather see an error if an immutable is violated. But wait, it does: perl -e'grep ++$_, -2..2' perl -e'grep ++$_, -2,-1,0,1,2' Modification of a read-only value attempted at -e line 1. perl -e'grep ++$_, @{[ -2,-1,0,1,2 ]}' So -2..2 just iterates mutables. -- Ruud
From: Jochen Lehmeier on 27 Jan 2010 15:03
On Wed, 27 Jan 2010 20:51:07 +0100, Dr.Ruud <rvtol+usenet(a)xs4all.nl> wrote: > perl -e'grep ++$_, -2..2' > > perl -e'grep ++$_, -2,-1,0,1,2' > Modification of a read-only value attempted at -e line 1. > > perl -e'grep ++$_, @{[ -2,-1,0,1,2 ]}' > > So -2..2 just iterates mutables. Aye. perl -e 'for (0,0) { print ++$_ for (1..2) }' 2323 So, the expression "1..2" is evaluated to an array at runtime, not compile time (if it were evaluated at compile time, the result would be "2334" instead of "2323"). No read-only values involved. Same goes for @{[...]}. I guess perl could optimize both constructs at compile time, but obviously doesn't, so it does not need to throw an error about read-only values. |