Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^4: Confused as to why the "casting context" is mis-behaving

by thargas (Chaplain)
on Oct 21, 2010 at 11:57 UTC ( #866534=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Confused as to why the "casting context" is mis-behaving
in thread Confused as to why the "casting context" is mis-behaving

You don't find the quote from perltrap interesting? Not even the fact that they have effectively the same assignment (from a list to a scalar) and claim that the result will be the length of the list? I.E. that note in perltrap is wrong, at least for those versions of perl that I have access to.

I do find that interesting because that's the first documentation I found when looking for what the documented behaviour would be. My method was look to grep perltoc for slice and context and then look in the pages it pointed at.

If this isn't going to be documented under the docs for slice (IMHO the correct place), then the other places need to be correct. Or we'll have people reporting bugs because they can't find the correct documentation.


Comment on Re^4: Confused as to why the "casting context" is mis-behaving
Re^5: Confused as to why the "casting context" is mis-behaving (trap)
by tye (Cardinal) on Oct 21, 2010 at 14:16 UTC

    The example from perltrap is unfortunately ambiguous.

    Not even the fact that they have effectively the same assignment (from a list to a scalar) and claim that the result will be the length of the list?

    No, it doesn't get the length of the list (literal). It gets the length of the array, which is the last expression in the list literal. The last word of the example is worse than ambiguous, it is misleading. One can argue that it isn't technically incorrect because $x does get assigned the length of the list of scalar values currently in the array, @y. But it certainly looks incorrect if you view it through the broken lens of the false dichotomy of "array vs list".

    I.E. that note in perltrap is wrong, at least for those versions of perl that I have access to.

    If you run the provided code in your copy of Perl 5 the output is not the documented "x = 3"? If so, then you should file a bug report.

    The example would not be ambiguous if slightly modified:

    Comma operator in scalar context gives scalar context to args

    The comma operator in a scalar context is now guaranteed to give scalar context to its arguments.

    @y= ('a','b','c','d'); $x = (1, 2, @y); print "x = $x\n";

    Perl4 prints: x = c # Thinks list context interpolates list

    Perl5 prints: x = 4 # Knows scalar uses length of array

    This illustrates why I said "be careful how you define 'item'". A list literal can be said to return its last "item" in scalar context. But it is much more accurate to say that a list literal in a scalar context calls the last expression in scalar context and returns (just) that result. A list literal is a syntax construct so "last item" means the last expression, whatever appears after the last literal comma in that part of the source code.

    A list literal can return a list of scalar values. But the last value of that list of values is not always the same as the "last item" that the list literal returns in scalar context. This further proves that a list literal is not the same as a list of scalar values.

    A slice in scalar context actually does return the last value. A list literal returns the scalar value of the last expression. The perltrap excerpt illustrates the difference.

    - tye        

      Oops. My mistake. I was tricked by the exact ambiguity you note. Thanks for the correction.

Re^5: Confused as to why the "casting context" is mis-behaving
by ig (Vicar) on Oct 21, 2010 at 17:54 UTC

    But I do find it interesting, as I said.

    In fact, that example led me to a much more correct understanding of what is happening. I wasn't aware of it and would never have looked for such insight into how literal lists behave in perltrap, so thank you for pointing it out.

    I agree that what you found in perltrap should be presented elsewhere. I had said Context but on further consideration I think List value constructors would be a better place. There is already an example with a scalar variable as the last "value" (using the terminology in List value constructors, though I wonder if that is the best terminology) in the literal list. I think the example from perltrap would be a fine addition to that section.

    I do think there are faults in the example in perltrap. I get the same result described with the version of perl5 I have tested with. I don't have any perl4 handy to test that prior behavior with.

    The description in perltrap is inconsistent with perl 5.10.0 that I have recently been testing with. The description says:

    The comma operator in a scalar context is now guaranteed to give scalar context to its arguments.

    Consider:

    print "Scalar assignment:\n"; $x = ( context(1), context(2), context(3) ); print "\$x = $x\n\n"; print "List assignment:\n"; @x = ( context(1), context(2), context(3) ); print "\@x = @x\n"; sub context { my $arg = shift; if(wantarray) { print "$arg: list context\n"; return("oranges", "lemons"); } elsif(defined(wantarray)) { print "$arg: scalar context\n"; return("apples"); } else { print "$arg: void context\n"; return("into the..."); } }

    Which produces:

    Scalar assignment: 1: void context 2: void context 3: scalar context $x = apples List assignment: 1: list context 2: list context 3: list context @x = oranges lemons oranges lemons oranges lemons

    So, the example says the comma operator is guaranteed to give scalar context to its arguments when evaluated in scalar context, but in perl 5.10.0 I see void context in some cases.

    This raises yet another issue: what does the comma operator (or any operator) do in void context?

    perlop says the comma operator is left associative. I take this to mean that ( 1, 2, 3 ) is the same as ( ( 1, 2 ), 3 ) rather than ( 1, ( 2, 3 ) ). If I am correct, one description of the comma operator that is consistent with my observations would be:

    In scalar context, the comma operator evaluates its left argument in void context and discards any result then evaluates its right argument in scalar context and returns the resulting scalar.

    In void context, the comma operator evaluates both its arguments in void context and returns nothing.

    But, I haven't looked at the internals of perl, and this may be more of the nonsense that so frustrates tye.

    While tye said the comment at the end of the example you quote is misleading, I would go further and say it is wrong. It should say (IMHO) "Knows scalar uses length of array", as tye said. The ambiguity is, I think, in which "list" is referred to in the last comment in the example. The comment is correct if one considers it to refer to the list of values in the array @y, but incorrect if one considers it to refer to the literal list ending with @y.

    More than reporting bugs, most people will continue to produce nonsense descriptions and explanations if this isn't better documented. This will lead to many surprises, which Perl/perl is supposed to avoid. In this case, I think better documentation is the most pragmatic means to reducing the element of surprise.

      The "scalar context" guarantee that the perltrap item is talking about is only for the last expression of the list literal. Yes, not clear as worded.

      I don't look at Perl internals much. I care a lot more about observable behavior. I mostly just have a lot of experience (mostly at PerlMonks) of watching people hit edge cases.

      Here's a recent edge case:

      print "Scalar assignment:\n"; $x = ( context(1), context(2), context(3) ); print "\$x = $x\n\n"; print "List assignment:\n"; @x = ( context(1), context(2), context(3) ); print "\@x = @x\n\n"; sub list { ( context(1), context(2), context(3) ) } print "Scalar assignment in sub:\n"; $x = list(); print "\$x = $x\n\n"; print "List assignment in sub:\n"; @x = list(); print "\@x = @x\n\n"; sub context { my $arg = shift; if(wantarray) { print "$arg: list context\n"; return("oranges", "lemons"); } elsif(defined(wantarray)) { print "$arg: scalar context\n"; return("apples"); } else { print "$arg: void context\n"; return("into the..."); } } __END__ Scalar assignment: 1: void context 2: void context 3: scalar context $x = apples List assignment: 1: list context 2: list context 3: list context @x = oranges lemons oranges lemons oranges lemons Scalar assignment in sub: 1: scalar context # shouldn't this be void context? 2: scalar context # shouldn't this be void context? 3: scalar context $x = apples List assignment in sub: 1: list context 2: list context 3: list context @x = oranges lemons oranges lemons oranges lemons

      I briefly believed the reason for the scalar (not void) context for the commented lines so that you don't get warnings from:

      use warnings; sub list { ('a','b','c') } my @all= list(); my $last= list(); # Doesn't produce a warning

      - tye        

        I believe the reason for the scalar (not void) context for the commented lines so that you don't get warnings from:

        I've always thought it was that the compiler can't perform static analysis across function calls. (By the time of assigning return values, does the compiler know that any element of the stack was a literal?)

        Scalar assignment in sub: 1: scalar context # shouldn't this be void context? 2: scalar context # shouldn't this be void context? 3: scalar context $x = apples

        It should be void, but it can't due to the way context is determined where it can vary at run-time. Known bug, but it can't readily be fixed.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2014-08-31 01:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls