A plain list, as I learned, is a comma-separated couple of values maybe in a pair of parens (just if operator precedence stipulates that). In scalar context, it shoves one value after the other into the single slot available, like it would distribute the values into the list context slots that will be discarded from tail to head unless saved in an array or in a couple of lvalue scalars (($foo, $bar) = ...). However actually implemented low-level, this at least is how it fits well into my overall knowledge of Perl. Mind the accordance to the fact that only what the last expression evaluated in a {...}-block returns is passed along the levels, and consider what $? would store from a system("longlist -of; external; commands") call, too.
But it is not that easy, there are caveats, probably more than the two I outlined in the test script. I'll try to generalize the problem: If your list consists of values equal in their kind, but you put expressions in your list that have a distinct scalar context behaviour on their own, then pray they don't happen to be evaluated in scalar context as caused by higher level in the callstack (beyond your control perhaps). This would render your list of indeed not-so-equal values overtly wrong and greedy of debugging time. If there is a means to provide scalar context, another to provide list context would not only solve a seeming lack in design (just a fan of symmetry that I am), but would also make for more robust module interfaces.
After all I've come to the conclusion that my feature request is well posted on PM. It would be ridiculous to consult p5p&co. as long as there are just two usage cases I can think of. But I'm looking forward to more cases posted by others.
| [reply]
[d/l]
[select] |
If there is a means to provide scalar context, another to provide list context would not only solve a seeming lack in design (just a fan of symmetry that I am), but would also make for more robust module interfaces.
It's possible to return a scalar in list context (since a single scalar is zero or more scalars), which is why scalar exists.
It's not possible to return a list in scalar context (since zero or more scalars isn't a scalar), which is why list doesn't exist.
Adding list would not improve symmetry or robustness; it would just lie about what you are doing. If you want a function that returns the last scalar of a list or scalar, list is a shitty name.
| [reply]
[d/l]
[select] |
Thanks, ikegami, for drawing me in the right direction. After another hard time thinking and reading I've got clearer sight. Apparently, in my understanding the list concept is too much of a "data unit" in its own right. It is not easy for me to revise that after 15 years of (partly intense) Perl development. But I will put it in order:
There are scalars, and there are aggregates of scalars (arrays and hashes). Whereas these are referred to as data types, lists do not form a data type at all. Lists are a purely syntactic concept, simply in no different from, say, an addition except the fact that the operator is a comma, not a plus sign. The comma discards, in scalar context, the left operand and evaluates to the right one. This behaviour I guess is only reasoned by consistency with similar constructs and because C does it and because throwing an exception would be lame, even ridiculous.
"List context" refers to the ability of the right side of an assignment, or of an operator respectively, to accept more than one value at once, so the commata will just pass all their operands in sequence. And that is all to it.
Almost, indeed. A list, as said to think of it as one or more commata with their operands in a chain, is often flattened. This means, any contained aggregates are deaggregated to their parts. So, if at all, a better name of such an operator would not be list but deaggregate, flatten or scalars_in and it would be applied in certain situations they are not flattened. (By the way, a third use case has come to my mind, it is merely theoretical as well, and taking into account Perl could do without for so long and considering its age and exhausted extensibility, three use cases still are far from enough ...)
sub modify3scalars (\$\$\$) { ... }
my @three = qw(values aggregated in_array);
modify3scalars(scalars_in @three);
# modify3scalars($three[0], $three[1], $three[2]);
# But alas! scalars_in %hash - in what order?
Perl 6 provides a pipe symbol to put in front of arrays in order to make signatures of them, hasn't it? Long time no revisit its synopses and try Rakudo &co. | [reply]
[d/l]
[select] |
