Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: If you believe in Lists in Scalar Context, Clap your Hands

by ig (Vicar)
on Oct 29, 2008 at 05:53 UTC ( #720164=note: print w/ replies, xml ) Need Help??


in reply to If you believe in Lists in Scalar Context, Clap your Hands

There appear to be two possibilities for LISTs:

One is that expressions that look like LISTs are LISTs regardless of whether they will be evaluated in list or scalar context, but the value and the process of evaluation depends on the context, as is generally the case with Perl.

When a LIST is evaluated in scalar context every element of the list is evaluated in scalar context and the value of the last element is the value of the LIST, with all the other values being discarded.

The other possibility is that expressions that look like LISTs are LISTs if and only if they are being/will be evaluated in list context but they are "what apperas to be a LIST"s if they are being/will be evaluated in scalar context. Commas in the part that is a LIST or a "what appears to be a LIST" are either list argument separators (not operators) or comma operators respectively. A statement may contain a LIST or a "what appears to be a LIST" depending on the context in which it is being/will be evaluated at run time and the rules for evaluating a LIST are different from those for evaluating a "what appers to be a LIST". The LIST only exists if the expression is being evaluated in list context and the "what appears to be a LIST" only exists if the expression is being evaluated in a scalar context. Therefore, there is no possibility of a LIST being evaluated in scalar context, avoiding considerable confusion.

When a "what appears to be a LIST" is evaluated in scalar context, by virtue of the comma operator, every element in the "what apperas to be a LIST" is evaluated in scalar context and the value of the last element is the value of the "what appears to be a LIST" with all the other values being discarded. (Note: all but the last element may be evaluated in void context rather than scalar context, but it still counts as scalar context for functions that care whether or not they're being called in list context.)

The former model is simpler and less surprising to me. It seems entirely consistent with the general rule that the interpretation of operations and values depends on context.

Whether any particular version of perl evaluates what appears to be a LIST in scalar context by evaluating all the elements in scalar context and using their values to initialize an ephermeral list value then discards all but the last value, or whether it has been optimized to evaluate all but the last element in void context (which is just a special case of the scalar context) and evaluate only the last element in scalar context and uses its value to initialize an ephemeral scalar value doesn't seem relevant to my understanding of Perl.

I suggest that the definition of Perl should be a simple and unsurprising specification of what the result of executing a Perl program will be, not a detailed specification of what perl will do when executing it.

clap


Comment on Re: If you believe in Lists in Scalar Context, Clap your Hands
Re^2: If you believe in Lists in Scalar Context, Clap your Hands
by chromatic (Archbishop) on Oct 29, 2008 at 06:40 UTC
    When a LIST is evaluated in scalar context every element of the list is evaluated in scalar context and the value of the last element is the value of the LIST, with all the other values being discarded.

    That explanation fails to account for operator precedence, so it's unworkable in practice.

      Would you elaborate on the affect of precedence on this please? With an example if possible.

        The proposed rule was:

        When a LIST is evaluated in scalar context every element of the list is evaluated in scalar context and the value of the last element is the value of the LIST, with all the other values being discarded.

        I said that doesn't account for precedence. Here's a very simple example:

        my $x = 1, 2, 3;

        Many people might say that 1, 2, 3 is a list, and it's obvious that my $x = supplies scalar context. The problem (at least for the proposed rule) is that = has a higher precedence than ,, so Perl's parser turns this code into three expressions:

        my $x = 1, 2, 3;

        Because the second and third expressions have no side effects (they're just constants) and they're in void context (use warnings to see that), they get optimized away. That's why they're not present if you use B::Deparse to see what Perl sees.

        (Besides that, this proves that the general rule "A list in scalar context evaluates to its final element" is wrong, too.)

        How about another example?

        my @y = 1 .. 8; my $x = @y, 2, 3; print $x;

        That's why I say the proposed rule has big problems. What looks like a list to a casual reader is often not the list that Perl sees -- and all of the talk about evaluating elements in scalar context and evaluating to the final element of the list is wrong.

      That explanation fails to account for operator precedence, so it's unworkable in practice.

      I don't understand your point. Can you give an example or explain how it fails to account for operator precedence?

      Note that I am talking about LISTs, not list values or all expressions that have list values in list context. I think it is necessary to distinguish between these three quite different things and that failure to do so is at the root of some of the confusion and disagreement that has been expressed.

      Update: chromatic responded to AM about the same time I posted this.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://720164]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (9)
As of 2014-12-27 18:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls