But even without a LISP background, you must know it's good to read
past the first sentence. The first two sentences are (and this is from
the 5.6.0 doc):

    Evaluates the BLOCK or EXPR for each element of
    LIST (locally setting `$_' to each element) and
    returns the list value composed of the results of
    each such evaluation.  In scalar context, returns
    the total number of elements so generated.

Considering that void context is a special version of scalar context,
the notion that map in void context would return a list *cannot* be
based on the documentation. At best, you would be discarding a *single*
value - just like do you when using print in void context.

// > @@  Until vs while is easy - again, the most readable one wins.  If your
// > @@  assertion is positive, use while, if it is negative, use until.
// >
// > So, you decide on for vs while and while vs until on a case by case
// > basis. That's good. However, you dismiss map right away.
//  
//  No - I use map more than I use for or foreach.  But that's primarily
//  because I am mapping problem spaces from one space to another more than
//  I am simply looping through constructs.

Well, we were discussing loops where we aren't interested in return values.
That is, where you could use map in void context.

// > @@ > ::         o   Avoid using grep() (or map()) or `backticks` in a void
// > @@ > ::             context, that is, when you just throw away their
// > @@ > ::             return values.  Those functions all have return val-
// > @@ > ::             ues, so use them.  Otherwise use a foreach() loop or
// > @@ > ::             the system() function instead.
// > @@ > ::
// > @@ > ::  I think this is the whole debate.  Unfortunately, there's no real
// > @@ > ::  explicit justification here.
// > @@ >
// > @@ > Which makes it just the personal preference of one man, doesn't it?
// > @@
// > @@  No - it means that the perlstyle authors (who are probably more
// > @@  proficient in perl than the both of us put together) thought this
// > would
// > @@  be obvious and unneeding of justification.
// >
// > Well, apparently it isn't obvious, and in dire need of a justification.
// > But I don't think Larry is going to do that. Some fragments of perlstyle:
// >
// >        Larry has his reasons for each of these things, but he
// >        doesn't claim that everyone else's mind works the same as
// >        his does.
//  
//  And Larry probably has better knowledge of perl than the rest of us.
//  Being a linguist rather than a purist, he doesn't force us to do things
//  his way, but that doesn't mean his thoughts aren't likely to be better.

I've heard Larry saying he seldomly uses 'strict' (and he had the code to
prove it). Damian, another rather well known Perl programmer hardly uses
'strict' either. Does that knowledge now make you stop using 'strict'? Or
do you form your own opinion on that?  I use map in void context because
*I* think it's ok, I'm not going to hide myself behind someone who might
be a better programmer.

//  Who said anything about studying the implementation?  I haven't studied
//  the implementation of map or for either - only their docs.  I *would*
//  expect that you would first study the perldoc on the module before
//  trying to use it... and if it documented two functions doing the same
//  thing, one that allocated and returned another object (whether ARRAY,
//  HASH or real object), and another that did exactly the same thing
//  without that allocation and return, then the point still stands.

Here's the 5.6.0 (because you still use that) doc about map. Could you
point out where in the doc it says it's allocating an array when map is
used in void context?

    map EXPR,LIST
        Evaluates the BLOCK or EXPR for each element of
        LIST (locally setting `$_' to each element) and
        returns the list value composed of the results of
        each such evaluation.  In scalar context, returns
        the total number of elements so generated.  Evalu-
        ates BLOCK or EXPR in list context, so each ele-
        ment of LIST may produce zero, one, or more ele-
        ments in the returned value.

            @chars = map(chr, @nums);

        translates a list of numbers to the corresponding
        characters.  And

            %hash = map { getkey($_) => $_ } @array;

        is just a funny way to write

            %hash = ();
            foreach $_ (@array) {
                $hash{getkey($_)} = $_;
            }

        Note that, because `$_' is a reference into the
        list value, it can be used to modify the elements
        of the array.  While this is useful and supported,
        it can cause bizarre results if the LIST is not a
        named array.  Using a regular `foreach' loop for
        this purpose would be clearer in most cases.  See
        also the grep entry elsewhere in this document for
        an array composed of those items of the original
        list for which the BLOCK or EXPR evaluates to
        true.

// > @@ > Then you shouldn't be programming in Perl. Because in Perl, you can't
// > @@ > do much useful without side effects.
// > @@
// > @@  Hmmm... I dunno - I've managed to do a lot of useful stuff without
// > side
// > @@  effects in perl.
// >
// > Really? Could you show some code? Remember, assignment and print are
// > only useful because of their side effects.
//  
//  I respectfully must disagree with your definition of "side effects".

    A language construct that modifies the state of the system. The most
    common side-effects are assignment, input and output. A language without
    side-effects is purely-functional - execution consists of the evaluation
    of an expression and all subexpressions are referentially transparent.

    http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=side+effect&action...

Now, you can make up your own definitions, but that's leading nowhere.