By its design, map is intended for use with arrays, not scalars.

lists, not arrays!

Arrays are those things that have @. And even then, an array used in list context evaluates to a list of its elements.

@foo                 # array
@Foo::bar            # array
@$foo                # array
@{ $bar }            # array
@{ $blah{blah}[1] }  # array
@list                # array with a confusing name

$array               # scalar (possibly a reference)
[ ... ]              # scalar (reference to anonymous array)
\@array              # scalar (reference to named array)
*foo{ARRAY}          # scalar (reference to the package global @foo)

print @array         # list (print "gets" a list, not an array, 
                     # because @array is in list context)
return @array        # list! (again, array in list context)

\(1, 2, 3)           # list of references, not a reference to a list

@foo =               # array
    map { $_ + 1 }   # list
    map { s/\n//g }  # list
    @bar             # list! (array in list context)
[download]

Please, learn the difference. It's confusing enough already even if you use the *correct* words.

You've put your chaining at a disadvantage in the ugliness department by illustrating it with mutators of $_. This technique shines in combination with other list operators like grep and sort, and when wrapped in a subroutine so that it acts on a copy of @_.

sub quux {
    my @args = @_;
    map { foo $_ }
      map { bar $_ }
        map { baz $_ } @args;
}
[download]

The real alternative is nested sub calls. While those look messy in C, with all the parens to be balanced, they have an equally nice expression in Perl, my $quux = foo bar baz $_;

One of the better reasons to use map in this way is the aliasing of localized $_ to each argument in turn. That is not a big advantage in your actions on a list of one element, but is a nice shorthand when operations act on $_ by default. You missed an opportunity to use that in the map { uc } stage.

Of course, this is all extremely powerful when acting on lists. The Schwartzian Transform is on anybody's list of "Best Dressed Perl".

The Schwartzian Transform is on anybody's list of "Best Dressed Perl".

Heh. Not the VP of Technology of a former workplace of mine who denounced an instance of the Schwartzian Transform in my code as "unreadable and unmaintainable." (It was commented as an ST, so any who didn't know it could look it up, but, of course, he already knew it was bad so he could save himself the bother of learning something new.)

Of course, his idea of good Perl was Perl trying to look like Java...

I disagree that ugly0 and ugly1 really are ugly. ugly0 is just list assignment syntax. ugly1 is just recognition that we need a return value from the map block. And in my mind, the only abuse of map, is when you use it in void context or throw away the return value(s).

Having said that, your example does not so much look like a pipeline to me. It looks more like a succession of operations:

my  $sBegin = "hello world";
my  $sEnd   = do {
  local $_ = $sBegin;
  s/hello/goodbye/g;
  s/world/todo el mondo/;
  uc;
};

print $sEnd;
[download]

When the only tool you have is map, every problem looks like a pipeline?

I like to use "for" for that kind of thing:

my  $sBegin = "hello world";
my  $sEnd   = $sBegin;
for ($sEnd) {
  s/hello/goodbye/g;
  s/world/todo el mondo/;
  uc;
};


print $sEnd;
[download]

I like to use "for" for that kind of thing

Me too, but I have found do{} is more readable. For one thing, it saves you from your bug: Your version throws away the uppercase string and so prints just "goodbye todo el mondo". My version would look like this:

my $sBegin = "hello world";
my $sEnd;
for ($sEnd = $sBegin) {
  s/hello/goodbye/g;
  s/world/todo el mondo/;
  $_ = uc;
};

print $sEnd;
[download]

TIMTOWTDI, but I think do{} is the more readable here.

Update: I trust you. No problem. But the bug still illustrates how the void context makes the for loop slightly less readable here. Such a bug (update: or the more likely opposite bug) could not as easily occur in the do{} block.

print "Just another Perl ${\(trickster and hacker)},"
The Sidhekin proves Sidhe did it!

ugly2 can be slightly less ugly:

  map {...} "$sBegin";    # quote to duplicate string
[download]

Hugo

"$sBegin" is not a true identity function. It forces string context on the variable, which may cause surprising problems in some code.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

sub{$sBegin}->() can be written @{ [ $sBegin ] }.

The one case were I frequently find myself “abusing” map in this fashion is to qr// a string built with function calls, usually a join with a bar:

my( $rx ) = map qr/($_)/, join '|', @alternative;
[download]

The other way to express this in condensed form is

my( $rx ) = do { local $" = '|'; qr/(@alternative)/ };
[download]

I'm not sure why I prefer the former (they're both kind of kludgy), but I do. :-)

Makeshifts last the longest.

The last "ugly0" is redundant

($sEnd) = map {uc}
          map {s/world/todo el mundo/; $_}
          map {local $_ = $_; s/hello/goodbye/; $_}
          $sBegin;
# Or:
($sEnd) = map {uc}
          map {s/world/todo el mundo/; $_}
          map {s/hello/goodbye/; $_}
          map {local $_ = $_}
          $sBegin;
[download]