IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Simple answer: there is no syntactic difference
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
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New OK, I think I get it.
Here goes:

Perl has scalars, arrays and hashes for data structures (scalars can be references). For passing a few things around, Perl uses lists. Lists are not goddamned arrays, goddamn your goddamned eyes, you goddamned sissy puspus programmer! Got it?

In all seriouosness, I think I understand much better now. Thank you very much for taking your (even more valuable now) time and producing a lucid explanation. This deserves to be written in some kind of global FAQ place, if it's not already there.
--

This guy's ahead of his time! He's using quantum programming methods: in universes where invalid data is passed to this function, it does not return. Thus you are ensured that you will only have valid data after calling it. Optimally you'd destroy the universe on failure, but computers haven't quite advanced to that level yet.

-- [link|http://thedailywtf.com/archive/2004/10/26/2920.aspx|The] Daily WTF

New Yup, sounds like you've got it
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
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
     One line description of data model for Perl - (Arkadiy) - (33)
         Yep, you got it right. - (admin) - (1)
             You're not helping - (Arkadiy)
         Perl: Everything is... - (ChrisR)
         Over simplifying - (broomberg) - (1)
             linquistic versus data personalities - (tablizer)
         To pick up from what Barry said. - (static) - (4)
             No, everything is whatever Barry needs it to be - (Arkadiy) - (3)
                 The logic - (ben_tilly) - (2)
                     Keys... - (Simon_Jester) - (1)
                         Tie is NOT a module (and it sucks) - (ben_tilly)
         Well, Lisp - everything is a list or an atom... - (Simon_Jester) - (18)
             Atonm, list, hash... - (Arkadiy) - (17)
                 References are essentially pointers - (broomberg) - (7)
                     I am not trying to build anything in particular just now - (Arkadiy) - (6)
                         some answers - (cforde) - (5)
                             OK, another arbitrary distinction to remember - (Arkadiy) - (4)
                                 It's easy enough to test... - (Simon_Jester) - (2)
                                     Yes it is easy to test. - (Arkadiy) - (1)
                                         Testing has some disadvantages.... - (Simon_Jester)
                                 It isn't arbitrary - (ben_tilly)
                 References: pointers in languages that don't have pointers -NT - (FuManChu)
                 okay...look at it this way.... - (Simon_Jester)
                 PERL DOES NOT STORE LISTS!!! - (ben_tilly) - (6)
                     OK, in that case, what is (a,b,c) ? - (Arkadiy) - (5)
                         In which context? - (ben_tilly) - (4)
                             In the context of grammar and syntax - (Arkadiy) - (3)
                                 Simple answer: there is no syntactic difference - (ben_tilly) - (2)
                                     OK, I think I get it. - (Arkadiy) - (1)
                                         Yup, sounds like you've got it - (ben_tilly)
         lets try another viewpoint - (daemon)
         Sorry for not responding in this thread earlier - (ben_tilly) - (2)
             No worries. - (Arkadiy) - (1)
                 :-) -NT - (ben_tilly)

You got the chainsaw. Now find some meat!
90 ms