print array with separator?
in [Perl]
|
Prev: LibXML (XPATH) and escape
Next: Module name access
From: Ben Morrow on 27 Jan 2010 16:43 Quoth J�rgen Exner <jurgenex(a)hotmail.com>: > "C.DeRykus" <derykus(a)gmail.com> wrote: > >I prefer the for modifier but wish 'void' was a keyword for side- > >effects only map use. Dear Lord no. That's as bad as the people who insist on casting everything to (void) in C. Evaluating a function in void context is a perfectly ordinary thing to do, so why does it need a redundant keyword? > Doesn't > undef = map ..... > work (I didn't try it)? No, that's scalar assignment, which gives scalar context to the RHS. At runtime you get 'Modification of a read-only value attempted', of course. Ben
From: C.DeRykus on 27 Jan 2010 19:10 On Jan 27, 1:43 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Jürgen Exner <jurge...(a)hotmail.com>: > > > "C.DeRykus" <dery...(a)gmail.com> wrote: > > >I prefer the for modifier but wish 'void' was a keyword for side- > > >effects only map use. > > Dear Lord no. That's as bad as the people who insist on casting > everything to (void) in C. Evaluating a function in void context is a > perfectly ordinary thing to do, so why does it need a redundant keyword? I mentioned "crazies" but you're probably right. Rather than judicious use in cases like map to bridge changed semantics, it'd turn viral. > > > Doesn't > > undef = map ..... > > work (I didn't try it)? > > No, that's scalar assignment, which gives scalar context to the RHS. At > runtime you get 'Modification of a read-only value attempted', of > course. > Ah. I suppose you could still signal map's only purpose were the side-effects with '() = map ...' (added keystrokes+slower though) -- Charles DeRykus
From: C.DeRykus on 27 Jan 2010 19:41 On Jan 27, 11:51 am, "Dr.Ruud" <rvtol+use...(a)xs4all.nl> wrote: > Jochen Lehmeier wrote: >> ... > > 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. > That seems wrong (or at least surprising) because the range op should just generate a list - in this case a list of literals - not an array of mutables. That is, these two appear to be equivalently processed by grep: perl -e 'grep ++$_, -2..2' perl -e 'grep ++$_, [-2..2]' grep appears to be creating a temp array in the former case instead of a list. -- Charles DeRykus
From: Uri Guttman on 27 Jan 2010 19:54 >>>>> "CD" == C DeRykus <derykus(a)gmail.com> writes: CD> perl -e 'grep ++$_, -2..2' CD> perl -e 'grep ++$_, [-2..2]' CD> grep appears to be creating a temp array in the former case instead CD> of a list. the second line makes no sense as it is passing an array ref to grep. perl -le 'print grep ++$_, [-2..2]' 162189897 the ref address get numified and then gets bumped. as for the other issues about modifying the ranges vs a list, possible this is from the optimization that perl does with large ranges. it used to generate them as a list and now it creates an iterator. another thought is that to make a range list it needs to create real sv's so it can bump them. but a list of ints is passed as constants and so they can't be modified. this harkens back to a bug i found when 5.6 changed qw() from a runtime split (which made sv's) to a compile time list of constant strings. some code i was analyzing for porting to 5.6 was crashing due to modification of constants in the qw. this feels like a similar thing. a generated list has to be sv's which can be modified. a passed list of constants are still constants and can't be modified. uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: Ben Morrow on 27 Jan 2010 20:18
Quoth "C.DeRykus" <derykus(a)gmail.com>: > On Jan 27, 1:43�pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > Quoth J�rgen Exner <jurge...(a)hotmail.com>: > > > > > "C.DeRykus" <dery...(a)gmail.com> wrote: > > > >I prefer the for modifier but wish 'void' was a keyword for side- > > > >effects only map use. > > > > Dear Lord no. That's as bad as the people who insist on casting > > everything to (void) in C. Evaluating a function in void context is a > > perfectly ordinary thing to do, so why does it need a redundant keyword? > > I mentioned "crazies" but you're probably right. Rather than > judicious use in cases like map to bridge changed semantics, > it'd turn viral. There are no changed semantics, just an optimisation. > > > Doesn't > > > � �undef = map ..... > > > work (I didn't try it)? > > > > No, that's scalar assignment, which gives scalar context to the RHS. At > > runtime you get 'Modification of a read-only value attempted', of > > course. > > > > Ah. I suppose you could still signal map's only purpose were the > side-effects with '() = map ...' (added keystrokes+slower though) That's a list assignment, so the RHS is in list context (it *is* possible to try these things before posting, you know). Ben |