|
in reply to Re^3: If you believe in Lists in Scalar Context, Clap your Hands
in thread If you believe in Lists in Scalar Context, Clap your Hands
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. |
Re^5: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief (Monsignor) on Oct 29, 2008 at 22:52 UTC
|
Taking into account operator precedence in your first example, the 1 is all that's in scalar context. There is nothing to present a list to the assignment operator at all, and each element item to the right of the assignment operator gets its context separately (two thirds of them getting void context).
Likewise taking into account operator precedence in your second example, only @y is in scalar context. The exception that an array in scalar context yields its length is in effect, and that's what $x gets assigned.
No lists are presented to the operators due to comma being lower in precedence than assignment. I don't see how one's thinking about lists even becomes involved with the thinking about the assignment unless someone doesn't know that the comma operator is lower precedence than assignment.
If someone doesn't understand operator precedence, they have bigger issues than just a mental model of lists.
BTW, I've never programmed more than a couple of dozen lines of Python, total. I also think candy-flavored unicorns sound delightful, if a bit dangerous to taste.
Now, if we were dealing with a concept of lazy vs. eager assignment operators or specific atom and list assignment operators (which would need different names and not both be simply '=') instead of context being determined by the left operand of the infix operator, then that'd be another story. That'd be a different language, too, though. | [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Sometimes the illusion is more useful than reality.
If you doubt this, consider all the useful 3D representations you use daily, drawn on 2D surfaces...whether they be games or icons or "3D bar charts" drawn on computer screens; or photos or painting around your home or office; exploded views in assembly manuals; signposts and diagrams of all kinds.
Further, 'inaccurate conceptual models' can serve both the beginner and the expert alike.
If you covered any electrical or electronics in your education, you probably started off thinking that "electricity flows from positive to negative". And then got pissed with your previous instructors when they queered the pot by telling that electrons actually flow from negative to positive. And then queered it further by telling you that most of the equations you would need for real world electrical and electronic engineering would require you to continue signing your electrical quantities as if the former was true; due to convention.
Getting hung up on reality has probably been the downfall of more students come exam time than inability.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re^5: If you believe in Lists in Scalar Context, Clap your Hands
by ig (Vicar) on Oct 29, 2008 at 18:47 UTC
|
I don't mean to be argumentative, but I am as yet unconvinced that the rules I gave are unworkable in practice.
To begin on a positive/agreeable note... you say:
What looks like a list to a casual reader is often not the list that Perl sees
I agree completely. And this problem is exacerbated by the lack of a clear definition of what is a LIST in the Perl documentation.
Many people might say that 1, 2, 3 is a list...
The rule I gave is a rule for evaluating a LIST in scalar context. It is not a rule for determining what part of a statement is a LIST or what the elements of the LIST are.
Other rules are required to determine what is a LIST and your example illustrates some of the complexity of doing so. It does not convince me that the rule I gave is unworkable in practice.
While some statements are difficult to parse, others are simple. The use of optional parentheses can simplify the task which otherwise, as you point out, requires an intimate knowledge of precedence and other rules.
The fact that some statements are difficult to parse does not mean that there is no such thing as a LIST in scalar context.
...they get optimized away...
The rule I gave was a rule describing the semantics of Perl, not the algorithms of perl. That perl can and does use optimized algorithms for executing Perl programs is a good thing as long as it remains consistent with the syntax and semantics of Perl. I don't agree that an optimization in perl for some particular case makes the rule I gave unworkable in practice.
(Besides that, this proves that the general rule "A list in scalar context evaluates to its final element" is wrong, too.)
I don't understand how it proves this. Can you explain further?
The value of any expression evaluated in void context is discarded. This does not invalidate a rule defining what the value of the expression is. That perl is optimized to skip steps that have no side effects when evaluating an expression in void context does not, in my opinion, have any bearing on what the value of a LIST in scalar context is.
I am talking about the semantics of Perl and you seem to be talking about the operation of perl. It is natural then that we should have different opinions about what is or isn't and what happens.
Update: fixed a typo in the last sentence
| [reply] |
|
|
I am talking about the semantics of Perl and you seem to be talking about the operation of perl.
Where do you think the semantics of Perl come from? The holy writ of magic candy-flavored flying unicorns? (However more maintainable that might be, there are actual and deterministic algorithms behind those semantics, which is sort of exactly precisely what people expect from a programming language.)
Feel free to argue with you think the semantics of Perl should be. Unless they match the documented and tested and empirically verifiable behavior of multiple versions of Perl, they're wrong, and you're wasting your time.
However much someone used to Python might think that parentheses make a list of constant expressions into a list in Perl, they don't. They merely group the expressions to disambiguate intended precedence. Perl's semantics aren't a matter of anyone's fiat, unless you want to anthropomorphize the code.
| [reply] |
|
|
I am increasingly inclined to agree with you, that Perl is not a language in its own right but merely a description of what some perl program does.
Even so, abstractions can facilitate use and understanding. Perl and perl should be consistent, but to the extent that Perl is an abstraction rather than the full source code, it comes from people trying to understand and explain perl rather than from perl itself.
In addition to facilitating understanding and use, elaboration of simple and unsurprising abstractions can help to identify ways in which perl and Perl might be improved. What it could and possibly should be is not what it is, but that doesn't mean discussing these possibilities is a waste of time. Without such discussion, there would be little basis for deciding what do do in the next release.
This particular Meditation may never inform or motivate an improvement in perl, but some do. Or are the developers of perl so remote from PerlMonks that nothing here makes any difference to what they do?
| [reply] |
|
|
