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

I think the problem is program code vs. execution.

Look at this code:

sub foo {
    ...
    return ($x, $y, $z);
}

[download]

By the definition, this sub returns a list. We all know that during runtime, it might not be a list, but how else would you describe what the sub is returning shortly?

Now this code:
my $x = foo();
This is a function call in scalar context. Now, together with the definition of the subroutine above, the sub somehow returns the list in scalar context. By definition. Which, during runtime turns out to be a scalar, because the list never existed, because perl knows the context early enough. So I would agree there is no list in scalar context during runtime, but for me it's clearly describing what code does. Whenever I read another post "There is no list in scalar context" I think, *sigh*, yeah, there might never exist such a list, but it's a good description of the behaviour.

Replies are listed 'Best First'.
Re^2: If you believe in Lists in Scalar Context, Clap your Hands
by JavaFan (Canon) on Oct 24, 2008 at 11:37 UTC
    By the definition, this sub returns a list.
    No, it returns the value of the last expression, evaluated in the context the function was called in. In your example, the expression is the comma operator.

    Note also that: 

    sub look_ma_I_am_returning_an_empty_list {
    return ();
}

    [download]
    actually returns a value in scalar context: the undefined value.
[reply]
[d/l]
      No, it returns the value of the last expression, evaluated in the context the function was called in.
      I know that, you know that, most of the others know that. Where's the problem?For me, a list(!) of scalars with the comma operator in between is a list. In english. To say that my example sub returns a list (I could even say here *every* sub returns a list) isn't saying anything wrong. If there is no list at all in perl, then it's clear I mean the english wort list. In my example I could also say three scalars.

      The point I want to make is whenever someone explains a piece of code with "list in scalar context" then you can be sure somebody who has too much time will correct them. But they didn't have the time to explain the piece of code in the first place. When you're talking about code, do you always use that long definition with the comma operator? If there is no list in perl, do you really *never* use this word when talking about code? Come on. I want to know what's wrong with using that word when explaining others the behavior of a piece of code. Didn't you get my point about code vs. execution?

      edit: or maybe your suggestion is, never use the word list, but use comma operator. I'm not sure if it's the right thing to always say "sub x returns the comma operator" when a) a list is a word that everybody understands and b) a list is used as a synonym for comma operator, so it doesn't say anything wrong. Couldn't we just say that? I never see where the explanation "list in scalar context" is saying anything that is not true.

[reply]
        In my example I could also say three scalars.
        But three scalars aren't returned when the sub is in scalar context. A single scalar is returned. Just as if you had 
        return $a + $b + $c;

        [download]
        again, in English, a list of three scalars separated by plus signs. But the sub doesn't return three scalars, it just returns one.
        If there is no list in perl, do you really *never* use this word when talking about code?
        I also said lists is mostly a concept for humans to work with. I said that when responding to a question regarding the difference between arrays and lists. Does that answer your question? Or do you need proof I actually communicate with humans?

        I've no problem with using the concept of lists. The problem is, not everyone is clear on what a list is. Some in this thread have shown a difficulty in grasping the difference between an array and a list. Others think lists can exist in scalar context. You prefer using "list" in a grammatical sense. So, sometimes, it's better to not use "list" as it only leads to confusion.

[reply]
[d/l]
      it returns the value of the last expression, evaluated in the context the function was called in

      For a start, you'd have to modify that with s[was][will be].

      Like I say, the alternatives suck! Bigtime!

      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]
[d/l]
        For a start, you'd have to modify that with s[was][will be].
        Indeed, that is precisely the Perl 6 solution to the problem: time travel. Context in Perl 6 is not determined at compile time or even at evaluation time, but rather at binding time, which is even later than that. Think of it as JIT context.

        'Course, Perl 6 also defines what it means to have a list in scalar context, and unlike Perl 5 defines it to not throw away information. You never get return-the-last-value semantics unless you ask for it specifically via subscripting. A list in scalar context just turns into an array object. An array in scalar context also just remains an array object rather than presuming that scalar context means numeric context. This lazy kind of time travel means the array can behave correctly and consistently in numeric context, boolean context, string context, or even, horrors, referential context.

        Unfortunately, you also need time travel to have a finished Perl 6. Fortunately it's the kind of time travel that can be implemented by waiting, as long as someone else isn't... :)

[reply]
        Your functions return now when they are called in the future? My functions only return after they have been called. That does suck in comparison.
[reply]

In Section Meditations