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
\_______/
Or viewed as named operators:
_______________________
/ \ \
| |1 |2
v | |
say(scalar(aassign(list($a, $b, $c), list()))
^ |
| |3
\____/
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.
|