You'll save yourself a lot of confusion if you memorize the above sentence.

A list in Perl is a temporary data structure that (in list context) is passed somewhere. Once the operation is done, the list is gone. Vanished. Kaput. You might store the list in an array. But an array is not a list. An array is a bag that contains a list of things.

So you can't create a list of lists in Perl. Doesn't exist. If you try you'll get one long flat list. You can create an array of references to arrays which accomplishes the same goal. But it isn't a list of lists.

Cheers,
Ben

In list context it produces a list that something is hopefully done with. In scalar context it returns the last element in the list (if the list is empty, then undef).

But my point is that the list is a transient thing. It is not a data structure that will exist to the next statement: it is produced and consumed within one statement. It is how Perl passes data around, not how Perl stores data.

If you try to think of it as anything other than the semantics indicated by Perl's grammar, you'll confuse yourself. Because that is all it is.

Cheers,
Ben

In most code the two behave exactly the same. If you're trying to build a simple model of how Perl works, stop there.

Now for some the gory details and minor quibbles. In function calls you can get a slightly different behaviour, and it is a judgement call about whether to think about this as there being a syntactic difference, or whether you think of the way it behaved in assignment to be the same as the function case - just with the default behaviour. I'd lean towards saying that the syntax is the same - but only functions can specify non-default behaviour.

Explaining that will take a bit.

First of all what is a list? A list is what you'd guess naively, an ordered list of things. Think of shoving a bunch of stuff on the stack - that's a list. In fact I believe that that's how Perl actually works internally, it sticks pointers to the list on the stack, and calls an operation that is supposed to do something with those arguments. When the opcode finishes, the stack is cleared. This all happens at the C-level, all actual Perl data structures are kept in the heap. They have to be because their lifetime is indeterminate when the data is created. (Note that in Perl 6 even lists will be created in the heap to allow continuations to be added to the language. This is very similar to Python vs Stackless Python.)

Arrays and hashes and most functions will accept a list and do something intelligent with it. If you assign the list to an array, the array is filled with that list, element 0 goes to element 0, element 1 goes to element 1 and so on. If you assign the list to a hash, it is interpreted as a list of key/value pairs and the hash is set up accordingly. If you call a function the elements of the list are aliased to @_, and the function is supposed to get the arguments from there.

Hopefully the idea of a list is fairly clear - it is supposed to be straightforward.

Now we come to the non-straightforward part. Normally when you call a function, everything is expanded out. So if you see something like:

\n  foo(@stuff, @more_stuff, bar());\n

then foo will get a list containing everything in @stuff followed by everything in @more_stuff followed by what bar() returned. But there are exceptions. For instance:

\n  push(@stuff, @more_stuff, bar());\n

adds the contents of @more_stuff and the return of bar() to the end of @stuff. The push built-in has something (mis)named a prototype that causes the generated list to be (\\@stuff, @more_stuff). You still get a list - just a slightly different one than you would expect.

This was originally shoehorned in for backwards compatibility. In Perl 1-4 these built-ins had special behaviour, and there was no good way to get the same behaviour for user-defined functions because you didn't have references. Through Perl 5 the capability to write functions that behave the same way as these special built-ins has been added. Using this capability is generally a very, very bad idea. For a full explanation of how it works, what it does, and why it is a bad idea, read [link|http://library.n0i.net/programming/perl/articles/fm_prototypes/|FMTYEWTK About Prototypes].

Now that I've explained this whole prototype thing, you see that it is possible for functions to get a slightly different list than you'd expect just looking at the argument list. However the default behaviour is, "expand everything expandable out into a flat list". If you're assigning to array you get this same default behaviour. With functions you have some control over how this list expansion works. With array assignment you don't.

Cheers,
Ben

As for a global FAQ, the perldata manpage attempts to explain this, along with the full syntax involved. The information is there - but the problem for the reader is extracting the information that you need from the mass of information that you might possibly need. (A problem which is complicated by the fact that different people need different pieces of information.)

Cheers,
Ben