in reply to Re^3: What's most efficient way to get list context? (count)
in thread What's most efficient way to get list context?

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

[download]
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.

the lowliest monk

Replies are listed 'Best First'.
Re^5: What's most efficient way to get list context? (count)
by merlyn (Sage) on Apr 15, 2005 at 14:44 UTC
    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}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
[d/l]
      I submit that a slice is a form of a list. By "a form of a list", I mean that its behavior is exactly like the literal list of the elements would be. In scalar context, it returns its last element, but there is no comma operator at work. Is that undocumented behavior?

      I think it's reasonable behavior, and I think it's reasonable to have the concept of a list apart from the comma operator.

      Caution: Contents may have been coded under pressure.
[reply]
        A slice is an operator, yet another kind of "node" using my terminology up-thread. A slice in a list context does the listy thing. A slice in a scalar context returns the last element, but could have been made to invoke nethack again. It has nothing to do with the comma operator, which has its own scalar/list behavior.

        The only consistency is that Larry made some of them consistent. It's DWLM: "Do What Larry Means". But it is learnable, and does make sense once you learn it.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]

In Section Seekers of Perl Wisdom