Hm. Seems to me that a list in a scalar context does return the last item:

print scalar (1,2,3);;
Useless use of a constant in void context at (eval 18) line 1, <STDIN>
+ line 16.
3
[download]

And map and grep each return lists ...

...except, when they find their return context is SCALAR they chose not to return a list, but instead they return a scalar, which happens to be the size of the list they would have returned had they found themselves in a list context.

...except also when they find themselves in a void context, in which case they chose not to return anything at all.

It mostly a matter of words, but I think it is wrong to say "map and grep each return lists", when like any other perl function they can chose whether to return a list, a scalar or nothing at all depending upon the context in which they are called.

You do a good job of showing how the meme is seductive. Thanks.

Let's start with the original statement, verbatum, which is not picking on FunkyMonk since this is not even close to an unusual phrasing of the oft-repeated meme:

A slice returns a list and assigning a list to a scalar will just assign the last item in the list to the scalar.

That (somehwat implied) logical argument can be broken down into several pieces:

1. A slice returns a list₁
2. Assigning a list₂ to a scalar will just assign the last item of the list₃ to the scalar
3. Therefore, a slice in scalar context returns the last value from the slice

Now, for item 3 to make logical sense, the meaning of item 2 must be stronger than how it might be interpretted on its own. So it would be clearer to upgrade item 2 via s/a list/any list/ and/or s/will/will always/.

Hm. Seems to me that a list in a scalar context does return the last item:

print scalar (1,2,3);;
Useless use of a constant in void context at (eval 18) line 1, <STDIN>
+ line 16.
3
[download]

Certainly. It also seems to me that a slice returns a list. It also seems to me that grep, in precisely the same way, "returns a list". Therefore, it should seem to me that grep in scalar context returns the last item (but, of course, it doesn't).

You (as has become quite typical, when people try to defend this flawed meme) make an argument about how you can claim that "grep doesn't really 'return a list'". But go ask some average Perl programmer you run into "Does grep return a list?". If they immediately respond "Well, not really", I'll be quite shocked. If they say as you did, "No, that is wrong", I'll be even more shocked. But if so, ask them if a slice returns a list. If they immediately respond "Oh, yes, of course, always", then they are clearly a figment of your imagination. :)

A much better way to resolve the problems with this meme lies in quite a different direction (and thanks for also demonstrating that, even though I've gone over this many times over many years, there are no shortage of fine, very wise monks who appear to have missed it). So, back to our 3 statements.

Consider "2) Assigning a list₂ to a scalar will just assign the last item of the list₃ to the scalar". As you so aptly demonstrated, what "list₂" means here is better termed "list literal" or, perhaps more accurately but certainly more awkwardly termed "the use of the comma operator within parentheses". That is, the prototypical construct ('a','b','c').

Yes, a (any) "list literal" (often just referred to as just "a list" in many situations) certainly (always) returns some "last item" when used in a scalar context. So, in "1) A slice returns a list₁", do we mean that a slice returns a "list literal"? Of course not! How could a slice "return a use of the comma operator"? You can't even argue that a hash slice gets compiled into the same code as ( $h['a'], $h['b'], $h['c'] ) does, simply because it doesn't.

A slice returns a "list of scalar values" (at least when used in a list context). So "list₁" means "a list of scalar values" (perhaps with some extra qualifiers, or perhaps not, depending on one's point of view and perhaps even on which version of Perl is being discussed, etc.).

So "list₁" and "list₂" actually mean two quite different (but related) things. You certainly can't reasonably argue that "list₁" means "list literal". But perhaps you want to argue the other direction, that is, to claim that "Assigning a list of scalar values to a scalar will just assign the last item of the list₃ to the scalar".

Well, that would certainly be rather awkward to argue. But I'll also note an extra wrinkle you'd trip over if you did try to do that. Consider the following:

sub f { return( 'a', 'b', reverse(1..3) ); }
my @list = f();
my $scalar = f();
[download]

We see that @list gets assigned a list of scalar values [namely, ( 'a', 'b', 3, 2, 1 )]. So, if "Assigning a list of scalar values to a scalar will just assign the last item of the list₃ to the scalar", then surely $scalar gets set to the last item in that list of scalar values, namely 1. But no, $scalar gets set to "321".

This is because "list₂" means "list literal" and "list₃" also doesn't mean "list of scalar values"; "list₃" means "the list of expressions that have been separated by commas". What gets assigned to $scalar is the value of reverse(1..3), interpretted in a scalar context. reverse(1..3) is the last item in the list of expressions that were separated by commas.

So what is true is that:

A list literal (use of the comma operator within parentheses) in a scalar context returns the value of the last (comma-separated) expression, itself interpretted in a scalar context.

Surely it is clear that this fact has very little to do with what a slice (array slice, hash slice, or list slice) returns in a scalar context.

And that is why the quoted meme is seriously flawed (despite producing a correct prediction in the case of a slice -- and wrong predictions in cases including grep).

---

Now, as for the competing meme that is used to counter the above meme, namely: "there is no such thing as 'a list in scalar context'"... I believe that it presents an important concept. Unfortunately, in an attempt to state this concept forcefully, it over-states it and thus is actually an incorrect statement.

As you correctly pointed out, there actually are several cases where Perl produces a list of scalar values (on the stack) despite this production being done "in a scalar context". But these cases are still "the exception" more than "the rule".

Perhaps a better phrasing of this competing meme would be (to paraphrase another famous phrase) "Perl abhors a list in a scalar context". Or, more clearly, "Perl rarely bothers to produce a list (of scalar values) when working in a scalar context".

But slices and grep are both examples where Perl (at least some versions of Perl) will do exactly that: produce a list of scalar values (on the stack) despite that list being produced "in a scalar context".

But we should also note that this "throw away most of the list and just return one scalar when confronted with a scalar context" is not automatic. The code to do that was missing for the case of a (hash(?)) slice prior to me submitted a patch many years ago. And Perl could dump core as a result. Every place that produces "a list in a scalar context" has to also have its own code added for taking care of throwing away most of the list. (Though Perl does defend itself against sloppy XS code, not requiring each XS function to take care of this situation itself.)

That is, there is, in fact, no general "just return the last item of the list" code in Perl. There are several specific cases of such code (as well as several specific cases of code that returns something other than the last item).

Finally, the moral of this story is:

When you see 'list' being used in reference to Perl, it can mean any of quite a few different things. And this is despite the fact that "scalar", "scalar context", and "list context" are each pretty preciesly defined for Perl.

And I didn't even mention that tr/.../.../ and regex character classes are each documented to use a "list" of characters and \w is even said to "generate a list". (:

- tye        

You ... make an argument about how you can claim that "grep doesn't really 'return a list'". ... But slices and grep are both examples where Perl ... will do exactly that: produce a list of scalar values (on the stack) despite that list being produced "in a scalar context".

Actually, it is the source that make that argument:

PP(pp_grepwhile)
    ...
    if (gimme == G_SCALAR) { // Scalar context
        dTARGET;
        XPUSHi(items);       // Choose the scalar that gets returned.
    }
    else if (gimme == G_ARRAY)
        SP += items;
    RETURN;
    }
...
[download]

That is, there is, in fact, no general "just return the last item of the list" code in Perl.

c:\test>perl -MO=Concise -wle"print scalar( 1, 2, 3 );"
Useless use of a constant in void context at -e line 1.
8  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
7     <@> print vK ->8
3        <0> pushmark s ->4
-        <1> scalar sK/1 ->7
6           <@> list sK ->7             <<< And yet, there it is.
4              <0> pushmark v ->5
-              <0> ex-const v ->-
-              <0> ex-const v ->5
5              <$> const[IV 3] s ->6
-e syntax OK
[download]

There are two important descriptions that can be applied to the affects produced by running a piece of code:

1. There is the detailed, 100% accurate, blow-by-blow, nitty-gritty description of what actually happens.
2. And there is the description of some abstraction (usually, one of many possible), that confines itself to describing those affects, whilst seeking to hide the details, as any good abstraction should.

Despite Perls' celebration of TIMTOWTDI, it has become derigour to only accept one abstract description of many of those affects. The problem is that the "one true abstract description", neither accurately describes the reality of what and how things happen, nor even provides a consistent abstraction to explain the easily observable affects. The results of these "one true way"-isms, is that we are left with no acceptable way to talk about things, that we write every day.

This ('a','b','c') is obviously, observably, more than one thing, because when we ask to print it:

c:\test>perl -wle"print for ( 'a','b','c' )"
a
b
c
[download]

When we place that thing that consists of more than one thing, in what I hope no one will dispute is a "scalar context", it produces a different result:

c:\test>perl -wle"print for scalar(( 'a','b','c' ))"
Useless use of a constant in void context at -e line 1.
Useless use of a constant in void context at -e line 1.
c
[download]

It (the thing) becomes; reduces to; produces; something different. A scalar value.

So, it's just a matter of agreeing a name or terminology that we can use decribe that thing: - A set of scalars? Too many connuctations. - A collection of scalars? Likewise. - A string of scalars? Not good. - A comma-separated sequence of scalar values? Possible, but what about the parens? They are important! Without them that comma-separated sequence behaves entirely differently:

c:\test>perl -wle"print for scalar 'a','b','c'"
a
b
c

c:\test>perl -wle"@a = (1,2,3); print for @a"
1
2
3

c:\test>perl -wle"@a = 1,2,3; print for @a"
Useless use of a constant in void context at -e line 1.
Useless use of a constant in void context at -e line 1.
1
[download]

So, whatever you term ( 'a','b','c' ), it is affected by context.

In a G_ARRAY context, it produces...um..itself really.

And in a G_SCALAR context it results in a scalar 'c'.

So, if ( 'a','b','c' ) is a 'list', then how do you describe putting that thing in a scalar context?

Surely it is clear that this fact has very little to do with what a slice (array slice, hash slice, or list slice) returns in a scalar context.

Now, I don't know about you, but this:

PP(pp_aslice)
{
    dSP; dMARK; dORIGMARK;
    register AV* const av = (AV*)POPs;
    register const I32 lval = (PL_op->op_flags & OPf_MOD || LVRET);

    if (SvTYPE(av) == SVt_PVAV) {
        const I32 arybase = PL_curcop->cop_arybase;
        if (lval && PL_op->op_private & OPpLVAL_INTRO) {
            register SV **svp;
            I32 max = -1;
            for (svp = MARK + 1; svp <= SP; svp++) {
                const I32 elem = SvIVx(*svp);
                if (elem > max)
                    max = elem;
            }
            if (max > AvMAX(av))
                av_extend(av, max);
        }
        while (++MARK <= SP) {
            register SV **svp;
            I32 elem = SvIVx(*MARK);

            if (elem > 0)
                elem -= arybase;
            svp = av_fetch(av, elem, lval);
            if (lval) {
                if (!svp || *svp == &PL_sv_undef)
                    DIE(aTHX_ PL_no_aelem, elem);
                if (PL_op->op_private & OPpLVAL_INTRO)
                    save_aelem(av, elem, svp);
            }
            *MARK = svp ? *svp : &PL_sv_undef;
        }
    }
    if (GIMME != G_ARRAY) {
    MARK = ORIGMARK;
    *++MARK = SP > ORIGMARK ? *SP : &PL_sv_undef;
    SP = MARK;
    }
    RETURN;
}
[download]

looks a lot like it pushes the sliced elements onto the MARKSTACK, (which is as good a definition of what a 'list' is in the full nitty-gritty description as I can think of), before deciding what the context is and then discarding all but the last element if it happens to be G_SCALAR.

So, if a list literal in the source, becomes a 'list' when it is pushed into the stack, doesn't it hold that when the multiple scalars produced by slicing an array is pushed onto the stack, it also becomes a list? And that all but the last element of that stack-held list of scalars are then discarded when in a scalar context?

Just as we say "I've boiled the kettle" not "I boiled the water in the kettle", with the subtle inaccuracy understood and glossed over. Or, "I flew to Rio" instead of "I boarded an airplane which flew to Rio".

Is it such a "bad meme" to say: A slice results in a list. And a list in a scalar context will return the last element of the slice? Rather than: an array slice constructor pushes the selected element of the array onto the markstack and if that array slice constructor is used within the confines of a scalar context then the stack pointer will be adjusted leaving just the last element accessible.

The oft-made observation that because of the scalar context, the comma operator reduces the thing (set of things, collection of things...) to a scalar before it ever became a list is both technically incorrect, and abstractly absurd.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

To be fair to FunkyMonk, there was nothing said about everything that can in any circumstance always returning the list last item of a list it took as an argument in scalar context. He said that assigning a list directly to a scalar does so.

In the case of grep, you're not assigning a list to anything. What you're assigning to the scalar is the return value from grep, which will be a list in list context and a scalar in scalar context.

I fail to see how the scalar return value from grep when called in scalar context is equivalent to the list returned by a slice.

...except also when they [map and grep] find themselves in a void context, in which case they chose not to return anything at all.

That is true as of Perl version 5.10 however in all previous verions they did "return" a list in void context.

Seems to me that a list in a scalar context does return the last item:

No. There is no such thing as a list in scalar context. Lists can only exist in list context. What you have here:

    scalar (1, 2, 3);
[download]

is the comma operator in scalar context. Of which man perlop says:

Binary "," is the comma operator. In scalar context it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value. This is just like C's comma operator.

except, when they find their return context is SCALAR they chose not to return a list, but instead they return a scalar

A feat not reserved for map and grep, but shared by every operator and function in Perl, including, without a single exception, all user defined functions. Anything that is in non-void scalar context will return exactly one value. And nothing will ever be returned in void context.

It mostly a matter of words, but I think it is wrong to say "map and grep each return lists", when like any other perl function they can chose whether to return a list, a scalar or nothing at all depending upon the context in which they are called.

You are mostly right. Except that a function or operator cannot chose whether to return a list, a scalar or nothing at all. It's the context that makes the choice - not the function.

No. There is no such thing as a list in scalar context. Lists can only exist in list context. What you have here: scalar (1, 2, 3); is the comma operator in scalar context. Of which man perlop says: Binary "," is the comma operator. In scalar context it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value. This is just like C's comma operator.

Sorry, but that is just (bad) semantics dreamed up (probably long after the fact), to try and explain what actually happens.

Proof: If the comma operator. In scalar context it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value..., then this should print undef or null or nothing, but it doesn't:

c:\test>perl -wle"print scalar(1,2,3,)"
Useless use of a constant in void context at -e line 1.
3
[download]

It's the context that makes the choice - not the function.

Okay. I can agree with that. The function can only chose whether to attempt to return a list, or some more meaningful scalar than the default reduction of that list, that the scalar context would otherwise make.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."