|
in reply to Re: There's scalar(), but no list(). Perl could need one for rare but reasonable use
in thread There's scalar(), but no list(). Perl could need one for rare but reasonable use
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. |
Re^3: There's scalar(), but no list(). Perl could need one for rare but reasonable use
by ikegami (Patriarch) on Jun 15, 2014 at 21:19 UTC
|
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] |
|
|
You are saying simply "list" to refer to what is more precisely referred to as a "list literal" (parens around a bunch of expressions separated by comma operators). This is quite often done, but you have to pay attention to the (English) context of the text to discern when. There are other places where simply "list" is used to refer to a "list of scalar values", a more general concept rather than a syntactical construct.
It is easy to get confused when reading multiple sources, some of which are saying "list" to mean "list literal" and some saying "list" to mean "list of scalar values". This is especially true because lots of the things don't conflict between those two concepts.
For example, calling a sub in "list context" certainly does not mean that the context of the call is part of a list literal. And an array stores a list of scalar values (that may have come from a list literal or not).
You seem to be struggling with trying to force features of list literals onto other types of Perl lists.
lists do not form a data type at all. Lists are a purely syntactic concept,
A list (of scalar values) is certainly a type of data in Perl. It isn't a "data type" to the point of being a type of variable (nor a type of reference). But a "list slice" can be performed on any list (of scalar values). A list is a common but ephemeral type of data in Perl (which is usually stored on the Perl stack).
When documentation talks about a 'sub' that "returns a list", it doesn't mean a 'sub' that has the 'return' keyword followed by a list literal. It means that calling the subroutine results in 0 or more scalar values being pushed onto the Perl stack and those being available at the point where the 'sub' was called. That is the type of data that the 'sub' returns to the caller. But that also only happens if the 'sub' was called from a list context.
See also Re^3: wantarray alternative (choice) and the rest of that thread.
| [reply] |
|
|
|
|
|
|
