You'll get a lot of people telling you that a "list" lives on the stack. You'll probably get a few people telling you that a "list" is things separated by commas. In fact, the word "list" is used for many different things in the Perl documentation and so anyone who tries to define it strictly for you is likely to cause you confusion when you run into one of the many parts of the Perl documentation that use the word "list" to mean something else.

In the Perl documentation, it is best to interpret "list" as an English word that describes several items of nearly any type associated together in a specific order. Within parts of the documentation, you will probably be able to infer more precisely what the word "list" is being used for within that section. But there are also parts where the word "list" is used in one way rather close to it being used in quite a different way.

An array, however, does have a rather precise meaning in Perl. It is something that you can push or pop or shift or unshift or splice. An array is a list of scalar values held in a structure that gives you access to make modifications to that list. It often has a name but it can be anonymous. Array is a type of Perl variable. You can take a reference to it.

The most important Perl concept that comes closest to being a "List" (capital "L") is better named "an operation that would return a list of scalar values if used in a list context". The concept of "a list of scalar values on the stack" is an oft-invoked image but I don't find it useful (unless you are trying to define "List", in which case it is certainly a simple definition, though a misleading one and not nearly the most important one, in my experience).

The "operation that would return a list of scalar values if used in a list context" aims right at the heart of Perl's list and scalar contexts. These will often be called "list" for short.

A list of expressions separated by commas is one way to write an "operation that would return a list of scalar values if used in a list context". Note that the list of expressions is not the same list as the list of scalar values that might be returned. This is important because, in a scalar context, this list of expressions returns the value that is returned by the last expression when it is called in a scalar context. This can be quite different from the last value of the list of scalar values that would be returned if the list of expressions were called in a list context.

Many have previously summed up what the above paragraph describes by saying that a list in a scalar context returns the last value of the list. So beware when you hear someone make restrictive proclamations about "lists" in Perl.

A list is an ordered collection of scalars. An array is a variable that contains a list. The two terms are often used as if they're interchangeable. But, to be accurate, the list is the data, and the array is the variable. You can have a list value that isn't in an array, but every array variable holds a list (although that list may be empty).

List Assignment

($fred, $barney, $dino) = ("flintstone", "rubble", undef);
($fred, $barney) = ($barney, $fred);
[download]

Array Assignment

@rocks = qw/ bedrock slate lava /;
@tiny = ( );                       # the empty list
$dino = "granite";
@quarry = (@rocks, "crushed rock", @tiny, $dino);
[download]

An array is an array, a list is a list.

An array is an ordered collection of values which lives in a permanent (more or less) location such as a named variable in the symbol table (e.g. $main::array or a named lexical (my @array = ( . . . )) (and yes, I'm ignoring references). A list is a temporary ordered set of values that lives on the call stack being put somewhere. An array in list context produces a list of the values it contains. An array can be used most places a LIST is expected, but not vice versa (for example push wants a literal array as its first argument).

It's a subtle distinction, but a few careful readings of perldata may eventually produce enlightenment.

The short answer is that lists live their transient lives in the stack; arrays live longer, in the heap. For a longer answer, see here.

But is there a difference between the terms "array context" and "list context", or are these terms used interchangably?

Ther perl function "wantarray" can distinguish between scalar and array contexts. If there is a difference between list and array context, I expect there should be an analogous way to distinguish these within code as well. Is there one?

FWIW, I did a meditation on context (scalar vs array) at Yet another List Versus Scalar Context Meditation.

Hope this isn't flogging a dead horse, just wanted to express this in a way that is clear to me.

"Context" in perl means, you have a line of code with a function that returns something, ie an lvalue -- for "left value" because what gets returned is on the left side of the expression. The function can behave differently, depending on what gets returned.

@array = myfunction(); # array or list context (same thing)
$array = myfunction(); # scalar context
[download]

If it's returning a scalar value it's scalar context, if it's returning an array value it is list context, or array context (same thing).

So, as far as "context" is concerned, array and list are the same thing.

But, there are places where the argument to a function has to be an array and not a list. So something like this could happen:

functionOnlyTakesArrays(@array) # works
functionOnlyTakesArrays("one","two","three") # doesn't work
[download]

Right? Or wrong?

No, there is no distinction in contexts, as far as return values from subroutines are concerned; I believe Larry Wall has admitted that the name really should be wantlist. The output is a list which can be used as-is or assigned to an array (or hash or whatever) if desired.

However, there are some subs which expect their arguments to be array variables (because the variable's data will be altered). Examples include pop() and shift().

--
[ e d @ h a l l e y . c c ]

However, there are some subs which expect their arguments to be array variables (because the variable's data will be altered). Examples include pop() and shift().

I think this is incorrect. Any list of arguments supplied to a subroutine are inserted into the array @_ and pop and shift handle that accordingly. There's no such thing as subs expecting array variables.