in reply to Re^12: 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 assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar().

You'll have to explain that. If it returns two values, what are they? How does it collapse into one value? How can you select which value you want? You're clearly speaking conceptually because that's not how perl is coded at all. So what advantages does your concept have?

  • Comment on Re^13: If you believe in Lists in Scalar Context, Clap your Hands

Replies are listed 'Best First'.
Re^14: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief (Monsignor) on Oct 25, 2008 at 20:59 UTC
    What bearing should the implementation have upon the concept so long as the concept is not describing a different end result? Isn't the whole point of different levels of abstraction to enable, in as many instances as workable anyway, people to disregard how things work at the lower level? The microcode in the processor knows nothing of sv_this and av_that, after all.

    Let's go with the idea that it's the list assignment operator that is the only thing returning anything there. It returns to the scalar() built-in the count of elements in the list. What returns results to the list on the left, which receives as many results as there are elements present to take them? Isn't that also the list assignment operator? If it's returning something to scalar() and it's returning something to ( $x, $y ) as well, then you have a single operator returning two results in two different contexts within the same expression.

[reply]
[d/l]
[select]

      I agree that abstraction is a very useful tool. But adding layers of abstraction for no reason is not better either. That's why I'm asking what value there is in your abstraction.

      Let's go with the idea that it's the list assignment operator that is the only thing returning anything there.

      I didn't realize that idea what proposed before, but ok. (I would say that say, scalar, both list operators, the assignment operator, $a, $b and $c all return something.)

      What returns results to the list on the left, which receives as many results as there are elements present to take them? Isn't that also the list assignment operator?

      If you're asking me what happens in your abstraction, I can't say, because I'm trying to understand your abstraction. So I'm going to assume you're asking what really happens.

      Does the "+" in "$p + $q" return something to "$p"? No.
      Does the "=" in "($a,$b) = ($c,$d)" return something to "($a,$b)"? No.

      You have the flow backwards. The assignment operator assigns to a list returned to it. 

                  ____
           /  | \
          2|  | |1
           |  v |
say(scalar(() = ($a, $b, $c)))
    ^         |
    |         |3
     \_______/

      [download]
      Or viewed as named operators: 
                   _______________________
            /     \                 \
           |       |1                |2
           v       |                 |
say(scalar(aassign(list($a, $b, $c), list()))
    ^      |
    |      |3
     \____/

      [download]

      If it's returning something to scalar() and it's returning something to ( $x, $y ) as well, then you have a single operator returning two results in two different contexts within the same expression.

      Ok, I understand your concept: You've renamed "assigns to" to "returns to". If that helps you understand how assignment operators work, great. On the other hand, introducing another definition for "return" is problematic.

[reply]
[d/l]
[select]
        Firstly, this isn't my abstraction. I never invented it and take no credit nor blame for it. I merely think that if it's helpful to someone, those of you who favor another abstraction shouldn't argue that it can't be helpful to them.

        Secondly, I know that infix operators could very well be rewritten as prefix or even as postfix operators or as prefix functions. That's not what is being discussed here.

        As I've said before, and I always tend to have to say when discussing this topic: I think there's merit in giving people pointers to an abstraction that is clearer to you, but that if they find an abstraction you find inferior clearer to them then why must you attack that abstraction?

        I think both ways of looking at this can be helpful. I think some people learn better by digging deeper and figuring out what happens at the lower level sooner. I think others prefer to learn a few rules and to learn convoluted exceptions. I really do think some people learn better that way. In fact, in many fields of endeavor people are taught first approximations of ideas, then exceptions, and later taught completely different ways of thinking about the same things.

        "'i' before 'i' except after 'c', except when it's an 'a' like in 'neighbor' and 'weigh'" ... except when it's not. Do you really expect kids just learning to spell to know which words are from French, German, Latin, and Greek roots? Irregular plural nouns are taught similarly. Gee, if only there was a programming language that was written by a linguist and could be learned piecemeal like a natural language...

[reply]

In Section Meditations