Re^3: A hint about using map

Right, that's a point, but the way I look at it it would still work even if s/// was returning the changed string (except, of course, when the returned string was something like zero or an empty string).

Really? Then what should s/// return if *no* substitutions took place? undef? That would make

    @new_list = map {s/foo/bar/} @old_list;
[download]

fail to do the right thing most of the time as well - it would only work if the old list only contain strings that would be affected by s///. You would still need to write that as:

    @new_list = map {s/foo/bar/; $_} @old_list;
[download]

most of the time.

Comment on Re^3: A hint about using map Select or Download Code

Replies are listed 'Best First'.
Re^4: A hint about using map by doom (Deacon) on Apr 08, 2005 at 20:31 UTC
Right, that's a point, but the way I look at it it would still work even if s/// was returning the changed string (except, of course, when the returned string was something like zero or an empty string). Really? Then what should s/// return if no substitutions took place? undef? That would make `@new_list = map {s/foo/bar/} @old_list;` [download] fail to do the right thing most of the time as well - it would only work if the old list only contain strings that would be affected by s///. You would still need to write that as: `@new_list = map {s/foo/bar/; $_} @old_list;` [download] most of the time. Yes, you're right. That was my first thought about how it should (or "should") work, and it was clearly ill-considered. My second thought was a little better (or so I think): `s///` could have been set-up to return the count of changes in scalar context, and the string itself in list context -- though that's perhaps a bit of an abuse of the idea of "list" context, because you're never going to have more than the one string returned from a `s///` (unlike a `m///`, which can have multiple captures). Also it would create it's own "DWIM" problem in another area... for example, while this would work: `@transformed = map {s/$old/$new/} @raw;` [download] This would not work: `$_ = $raw; $transformed = s/$old/$new/;` [download] Anyway, the perl 6 solution to these problems is add more contexts. If I understand correctly, in logical context `s///` will return whether the change happened, in numeric context you'll get the count, and in string context it'll return the matched string. So whether or not Larry Wall would agree that he "blew it" originally, he's going to fix the problem.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: A hint about using map
by doom (Deacon) on Apr 08, 2005 at 20:31 UTC

Right, that's a point, but the way I look at it it would still work even if s/// was returning the changed string (except, of course, when the returned string was something like zero or an empty string).
Really? Then what should s/// return if *no* substitutions took place? undef? That would make
    @new_list = map {s/foo/bar/} @old_list;
[download]
fail to do the right thing most of the time as well - it would only work if the old list only contain strings that would be affected by s///. You would still need to write that as:
    @new_list = map {s/foo/bar/; $_} @old_list;
[download]
most of the time.

s///

m///

  @transformed = map {s/$old/$new/} @raw;
[download]

   $_ = $raw;
   $transformed = s/$old/$new/;
[download]

Anyway, the perl 6 solution to these problems is add more contexts. If I understand correctly, in logical context s/// will return whether the change happened, in numeric context you'll get the count, and in string context it'll return the matched string.

So whether or not Larry Wall would agree that he "blew it" originally, he's going to fix the problem.

[reply]
[d/l]
[select]