list vs. array

[Ch Lamprecht]

?

Why did you snip the context you were replying to?

The expression (4,5,6) does not produce a list out of its own. It is dependent
on the context it's evaluated in.
In list context it evaluates to a list containing 3 values: 4 5 and 6.
In scalar context it evaluates to the value 6.

That is because the 'comma' operator
-In list context evaluates the expressions on his left hand - and right hand
side and returns a list containing of the results of these expressions.
-In scalar context evaluates the left hand side, discards it and returns the
result of the expression on its right hand side.

Christoph

 

[robb]

The expression (4,5,6) does not produce a list out of its own...

I don't understand the meaning of your post - I understand the facts,
but what conclusion are you implying? Is Tad's post incorrect? A list
is not created and returned by the function?

 

[Ch Lamprecht]

I don't understand the meaning of your post - I understand the facts,
but what conclusion are you implying? Is Tad's post incorrect? A list
is not created and returned by the function? No.

Sorry, if that was not clear
All I meant was, that his example is not about the list vs. array issue. It's
about evaluation of array and comma-operator in scalar context.

Christoph

 

[David Squire]

I don't understand the meaning of your post

And you don't give anyone else much chance either, as you repeatedly cut
too much context when replying. The part you snipped here was in fact
the explanation you are in search of.

- I understand the facts,
but what conclusion are you implying? ... A list
is not created and returned by the function?

Yep. As I learnt myself here only last week, the parentheses in, say,

@this_array = (4, 5, 6);

only fulfill a scoping function (to prevent '=' binding to '4' alone).
It is in fact the @this_array that provides list context on the RHS.
When in scalar context, e.g.,

$this_scalar = (4, 5, 6);

no list is generated at any stage. This is also mentioned in the FAQ
entry you were directed to earlier.


DS

 

[David H. Adler]

And you don't give anyone else much chance either, as you repeatedly cut
too much context when replying. The part you snipped here was in fact
the explanation you are in search of.



Yep. As I learnt myself here only last week, the parentheses in, say,

@this_array = (4, 5, 6);

only fulfill a scoping function (to prevent '=' binding to '4' alone).
It is in fact the @this_array that provides list context on the RHS.
When in scalar context, e.g.,

$this_scalar = (4, 5, 6);

no list is generated at any stage. This is also mentioned in the FAQ
entry you were directed to earlier.

And, to hopefully clarify through belaboring the point,

@this_array = 4;

doesn't make @this_array any less an array even though it only contains
one value at this point.

dha

 

[Ben Morrow]

Thanks - I hadn't seen it expressed this concisely up till now.

Is it advisable to think about these issues and consider them when
actually doing programming?

For example, when I work with lists and arrays, I usually focus on
issues such as do I want to be manipulating arrays or arrayrefs...
Which do I want to be using in my APIs, etc.

However, it is important to realize that you cannot pass an array to a
function, in Perl. You can expand the array into a list of its elements,
and pass that, or you can take a ref to the array and pass that: which
you choose makes quite a difference.

Ben

 

[robb]

...it is important to realize that you cannot pass an array to a
function, in Perl...

I seem to remember this, and so long ago I adopted a coding style of
only passing scalars - actual scalars and refs - in my functions.

I've that if that's the coding style, then everything "just works", and
also there's a consistency of what to expect, and how to use the code.

 

[Ben Morrow]

Hmmm, previous experience with you taught me that often you corrected
me on something that seemed to be clearly done in a certain way, but
actually wasn't. So I may well be wrong and I foresee the argument to
be controversial anyway, but aren't the \@ and \% prototypes (ok,
recommendations against using prototypes apart) a means to actually
"pass an array" (or hash) to a function. Indeed you pass a reference,
but this reference is taken transparently. From the syntactic pov of
function call it seems to me that the array or hash is actually passed
in. Again prototypes are limited, e.g. you can't pass in an arbitrary
number of arrays this way, yet the mechanism seems to provide an
exception to your claim.

Well, yes, you are correct. I was ignoring prototypes (and functions
like push, which predate general prototypes). From the POV of the called
function, though, it still simply receives a list, some of the members
of which may be arrayrefs.

Ben

 

[robb]

Quite limitative and inefficiency-prone. But if you're feeling fine
with it...

For sure, it's good maintenance-efficiency-wise. In what ways would it
be ineffiicient?