|P is for Practical|
Re^4: If you believe in Lists in Scalar Context, Clap your Handsby gone2015 (Deacon)
|on Oct 24, 2008 at 11:47 UTC||Need Help??|
But you had discussed arrays and hashes. Are you implying that array slice make lists and arrays don't?
Yes. I'd say that an array is a variable whose value is a list. Using the name or some other reference to an array yields that value or its length, depending on Context. In that sense, yes, I was implying that arrays do not make lists. A slice operation, on the other hand, takes a list value and makes a list which is a subset. (I'm open minded, though: if there is, in fact and invisible operator that makes lists out of arrays I would not be surprised.)
The omission seems rather "convenient" because it allowed you to cut two exceptions from the "in Scalar Context" list.
I'm sorry you've drawn that conclusion.
The last item in the list you refer to covers the case of arrays, pointing out that lists and arrays are not identical, and notes the effect of Context. For completeness I could have mentioned hashes, but their relationship to lists is, in my opinion, one step removed, and I did try to keep to the main point, namely Lists in a Scalar Context.
Exactly. A list can't be produced in scalar context. So how can a list be put into scalar context?
Just for a moment, let's consider integers and floats as two different sorts of value. Suppose we have the expression: 27 % 4.79 . Now, '%' is an integer operation -- one could say it has "Integer Context" -- and the floating point argument is implicitly coerced to an integer, suitable for the '%' operation. At least that is a common understanding of what happens.
You may argue that the thing which I referred to as a floating point value never was a such, because you cannot have a "Float in Integer Context". That would be consistent with the view that, in Scalar Context: 100 + @r[@p] the thing which looks a lot like a list isn't a list because you cannot have a "List in Scalar Context" (QED).
"List in scalar context" is deceptive, misleading and/or confusing.
It is definitely dangerous to assume that all things that return lists in list context will have "List in Scalar Context" semantics. Just as it is would be dangerous to assume that all numeric functions return the same sort of number. So one has to be careful.
However, where those semantics apply, which is not uncommon, I find it a less confusing notion than "it was never a list, no matter what it looks like". Cooercion is a well understood and common notion. I really don't see why it should not apply to lists. (It does to arrays.)
Assignment operators are right-associative. That means that in chain of assignments, the right-most has highest precedence. ** is also right-associative.>perl -le"print( 2**3**4 )" 2.41785163922926e+024
Thanks for the clarification. The right-hand '**' happens first, giving 81, then the left-hand '**' takes the 2 and the 81, giving a modestly big result. OK.
Following that model, in: $r = ($a, $b) = 0..11 ; the right-hand assignment: ($a, $b) = 0..11 happens first, so we get ($a=0, $b=1), then that is assigned to $r.... leaving to one side whether ($a, $b) is or isn't a list (given that for the right-hand assignment there's List Context, and in the left-hand one Scalar Context).... since the result is $r=12, right-associativity doesn't appear to be the whole story.
With thanks to all who pointed me in the right direction here, this is a piece of deeper magic. The right-associativity causes the 0..11 to be evaluated in List Context, and a list assignment is made to ($a, $b). So far, so straightforward. The interesting bit is that the next (left hand), scalar assignment, effectively reaches round the first (right hand) assignment and picks up the length of the list. This is well documented, but the significance of it didn't sink in when I read it however many years ago.
It's obvious to me now, of course. We're all used to using this magic, for example in: while (my($k, $v) = each(%h)). I admit that I had assumed that this was either because the assignment would leave the lvalue with no more entries in it than were available in the rvalue, or because the $v was undefined -- though I never tested either. I live and learn. (Though, sadly, wisdom eludes me.)
Ah well. It has been said that "There is no spoon". But some say it's worse than that (Jim), by extension there's no cutlery, no kitchen utensils, no stove, no kitchen and pretty soon I can expect to starve to death. I think I'll go and do something really dangerous now, I'll take away some brackets and to blazes with the sign.