| [reply] |
Something I can't remember returns the first item
caller, getpwuid, getpwent, more get* functions, but not all of them. get*nam return their third (or other) argument that they would have returned in list context.
localtime returns a pretty printed version of its list context value. readdir, <>, each, .. and m//g iterate in scalar context. qw populates @_ in scalar context. And then there are reverse and x.
| [reply]
[d/l] |
OK, here is what I was trying to convey when I wrote the line you quoted:
DB<1> @a = qw(foo bar baz)
DB<2> @h{@a} = (1) x @a
DB<3> p $s = () = @a
3
DB<4> p $s = () = (1, 2, 3, localtime())
12
DB<5> p $s = () = %h
6
DB<6> p $s = () = getpwuid($<)
9
DB<7> p $s = () = sort @a
3
As you can see, for all the cases you cited, when perl is coaxed into evaluating the RHS in a list context, and then the returned list is put in a scalar context, the result is the size of the list. I am not sure what is the correct wording to describe what I illustrate above, but it is clearly distinct from the fact that context-sensitive subexpressions will make idiosyncratic choices about how they respond to different contexts.
In fact, as I illustrated with the m// example in my first reply to you, it is precisely the fact that different context-sensitive operations will make idiosyncratic choices for how they respond to a scalar context that makes it desirable to be able to explicitly instruct these operations to assume a list context, which is what the = () = kluge does.
I readily admit that this is one of the areas of Perl that I have the hardest time with, as I've stated elswhere, so I really appreciate this discussion. I think our discrepancy here gets at the root of why this is such a persistent blind spot for me. As I'm beginning to understand it, there is a nasty tension between the whole DWIM thing on the one hand, and the idea that functions should do something "useful", even if idiosyncratic, depending on context. For DWIM to be possible, I think some consistency is necessary, otherwise "what I mean" will constantly be confounded by whatever usually-useful-but-idionsyncratic context-sensitive behavior functions may choose to adopt. But such consistency would prevent functions from behaving as usefully as possible. I think the only way to preserve both is to give the programmer the ability to explicitly specify context, just like we have the ability to explicitly specify precedence with ( )'s.
Update: Fixed link.
| [reply]
[d/l]
[select] |
when perl is coaxed into evaluating the RHS in a list context, and then the returned list is put in a scalar context,
No, you can't "put {a list} in a scalar context".
What you've done is demonstrate that the list-assignment operator ((...) = LIST) returns the number of elements assigned in a scalar context. This is both documented, and could just as easily invoke Nethack instead (although that would be less useful).
That has nothing to do with "list in scalar context", because "list in scalar context" can't exist.
It helps me to always think of the abstract syntax tree. Every node in the tree is some kind of operator/function. Every node is being evaluated in some sort of larger context (scalar/list/void, and to a lesser extent scalar can also be numeric or string). Every node can choose to return different things to each of those contexts.
In your example, the "top node" is "list assignment operator". If you evaluate that in a list context, it returns a copy of the contents. If you evaluate that in a scalar context, you get the number of elements copied.
At no time is there a "node" that has a strictly list value that is being evaluated in a larger context. In some sense, lists don't exist, except because someone applied list context to some node that can return a scalar or a list. Because there's no existing node that returns a list in a scalar context, it simply does not exist. You could probably write one in XS, and break things, but there's no existing one that does that. {grin}
| [reply]
[d/l] |
| [reply] |