Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

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

by oshalla (Deacon)
on Oct 23, 2008 at 21:38 UTC ( #719174=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^2: If you believe in Lists in Scalar Context, Clap your Hands
Re^3: If you believe in Lists in Scalar Context, Clap your Hands
by JavaFan (Canon) on Oct 23, 2008 at 21:55 UTC
    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?

        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.
        Right.

        Suppose I had claimed that birds are black. And oshalla disagrees, and shows pictures of ravens. Now, that wouldn't support his case, would it?

        If I say that lists are a concept for humans, and someone shows the manual page - which is intended for humans - mentioning lists, than it only supports my claim. It doesn't follow that my claim is true - but it certainly doesn't disprove it.

      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.

Re^3: If you believe in Lists in Scalar Context, Clap your Hands
by TGI (Vicar) on Oct 23, 2008 at 22:40 UTC

    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://719174]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2014-09-20 09:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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











    Results (158 votes), past polls