Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by JavaFan (Canon)
on Oct 23, 2008 at 19:58 UTC ( #719150=note: print w/ replies, xml ) Need Help??


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

I've -- your posts. You seem to advocate the "lists in scalar context" meme. Context in Perl is important, and while confusing for some beginners, not that hard. Except when you're lured into thinking "lists in scalar context".

The fact you're troubled by context (and related things) is proven by your final question:

Finally, and for extra points (and points mean prizes), how does one describe the difference between a list and an array ?
This is actually quite easy. "Arrays" are something the Perl runtime really knows about. They are represented as AVs internally. They can be sliced and diced, passed around, changed, etc, etc. "Lists" however are a human thing - to make it easier to talk about code. Perl doesn't know about lists. It knows about list context. But what humans call a "list" is for Perl just a sequence of scalars in list context.

And once you understand that, you never think about lists in scalar context again. It just doesn't make sense. Lists are there because the context is "list context".


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 BrowserUk (Pope) on Oct 23, 2008 at 21:21 UTC
    I've -- your posts.

    You felt the need to downvote them all?

    And I've downvoted your post for .... (I'll fill that in with an PC epithet later maybe.)

    Perl doesn't know about lists.

    What utter clap trap! perl may not know about lists, but Perl surely does.

    Else, how do you explain all the references to lists in the perl documentation? 244 in perlfunc alone. And thousands in the document set as a whole.

    And human beings use Perl. What goes on inside perl isn't, (and should not be) of any interest to the vast majority of Perl users. Weirdos like we two aside.

    All your talk about "AVs" and and "the internals" are far more damaging to Perl and novice Perl users, than any mild technical inaccuracy in a conceptual model that fits well with both the documentation, ethos and apparent behaviour of Perl.

    Perhaps that's why you call yourself a java fan?


    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.
Re^2: If you believe in Lists in Scalar Context, Clap your Hands
by tilly (Archbishop) on Oct 23, 2008 at 21:30 UTC
    Oh really?
    my @stuff = ("this", "that", "and", "the", "other", "thing")[0, 1, 5];
    It looks like I just sliced a list.
    print "Hello " . ("earthlings", "world");
    It looks like I just put a list in scalar context.

    However I agree that you can't do the other things you said you can't do without constructing something other than a list. Furthermore I'm the kind of person who never thought much of semantic arguments. I don't care what you call the construct, as long as you understand what it does.

      Quick! Bandaid that bleeding list! :p
Re^2: If you believe in Lists in Scalar Context, Clap your Hands
by oshalla (Deacon) on Oct 23, 2008 at 21:38 UTC

    OK. The implementation detail is obviously interesting, and one would hope that it is strongly related to the concepts it embodies.

    Taking a listy kind of Perl function more or less at random:

    • map BLOCK LIST
    • map EXPR,LIST
    Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each element) and returns the list value composed of the results of each such evaluation. In scalar context, returns the total number of elements so generated. Evaluates BLOCK or EXPR in list context, so each element of LIST may produce zero, one, or more elements in the returned value.

    I'm curious how this is to be understood if Perl doesn't know from lists.

      I didn't know Perl read the manual page.

      As I said, "List" is a concept for humans. The fact that LIST is mentioned in the manual page only supports that notion - after all, it's humans who read the manual page.

      For Perl, map just has a sequence of scalars as arguments.

        By your reasoning, the fact that strings are mentioned in the manual page supports the notion that strings are only a concept for humans, but are not really part of the Perl language.

        Are you truly unable to see the problem with this line of reasoning?

        Sorry, I think you're just acting stupid right now.

        perlfaq4 even has the question What is the difference between a list and an array?, and the answer isn't "there is no list in Perl".

        For the user of a programming language the internals of the interpreter are irrelevant, and if the documentation uses a notion all over the place, you'd do very well to accept that this thing actually exists.

        Calling things "sequence of scalars" instead of "list" doesn't make things clearer or more precise.

        Let's suppose for a moment that Perl, as a language, is a collection of concepts, without worrying too much about how a program written using that language is executed.

        It seems to me that in this language the list (or LIST) is an important element. It appears that lists may appear as arguments in expressions and may be the result of expressions.

        I can see that it is possible to take the view that lists (in this abstract sense) can only exist in List Context. Trivially then there can never be a List in Scalar Context.

        This view requires a Scalar Context variant for every instance of something that in List Context would return a list. The Scalar interpretation of ',' is well known. Similar definitions are required for slice operations, and for anything else that can return a list in the appropriate context.

        It's true that in the limit, Perl being what it is, the programmer should never assume any particular behaviour in a Scalar Context based on knowledge of the List Context behaviour.

        Bearing that in mind, there are two common Scalar Context results where a list is returned in List Context:

        1. the length of the list that would have been returned in List Context.
        2. the last item of the list that would have been returned in List Context.

        These are, of course, not the only results -- just common ones.

        As common as they are, my feeling is that these behaviours could usefully be given a name. Then using that name the programmer might reduce the intellectual load by categorising some things as Type-1 list operations and others as Type-2.

        It would be nice to have a more memorable or meaningful names for these... perhaps something that relates to concepts already understood ?

        I have a couple of fairly obvious suggestions. But perhaps I have uttered enough heresy for today.

      What I think JavaFan is getting at when he says "lists in scalar context" is a damaging meme is that there is no such thing, and he feels that this conception leads to serious errors of understanding.

      See perlop for why there is no such thing:

      A named array in scalar context is quite different from what would at first glance appear to be a list in scalar context. You can't get a list like (1,2,3) into being in scalar context, because the compiler knows the context at compile time. It would generate the scalar comma operator there, not the list construction version of the comma. That means it was never a list to start with.

      There's a bit more in the 'Comma Operator' section of perlop.

      So, when you have
          $r = (1, 5, 10)
      perl sees something like
          $r = 1 return_right_side 5 return_right_side 10;
      and
          @r = (1, 5, 10)
      becomes something like
          @r = list_constructor( 1 list_separator 5 list_separator 10 );


      TGI says moo

        See perlop for why there is no such thing:
        A named array in scalar context is quite different from what would at first glance appear to be a list in scalar context. You can't get a list like (1,2,3) into being in scalar context, because the compiler knows the context at compile time. It would generate the scalar comma operator there, not the list construction version of the comma. That means it was never a list to start with.

        The thing is, this is only a partial explanation.

        First, the issue is not entirely resolvable at compile-time. Take a subroutine that ends: return (1, 2, 3) ;   The compiler must either have a Context sensitive variant of the comma operator, or compile in the list version followed by code to tidy up afterwards to match the calling context.

        Second, literal lists are not the only lists. The most general example of that is the slice. I accept that these can be explained by reference to Scalar Context behaviour of the slice operators.

        But all of this can also be understood in terms of List in Scalar Context semantics -- a form of "default coercion", if you will. Without recourse to "it cannot be a list if it's not in List Context" mental gymnastics.

        And, for completeness, this is only effective with the caveat that to assume that this "default coercion" is universal will, sure as eggs is eggs, lead to tears before bedtime. But then, that's true of many defaults.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-09-16 11:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (10 votes), past polls