Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^3: There's scalar(), but no list(). Perl could need one for rare but reasonable use

by ikegami (Pope)
on Jun 15, 2014 at 21:19 UTC ( #1089965=note: print w/replies, xml ) Need Help??

in reply to Re^2: 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

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.

  • Comment on Re^3: There's scalar(), but no list(). Perl could need one for rare but reasonable use
  • Select or Download Code

Replies are listed 'Best First'.
Re^4: There's scalar(), but no list(). Perl could need one for rare but reasonable use
by flowdy (Scribe) on Jun 17, 2014 at 20:04 UTC

    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.

      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.

      - tye        

        Thanks a lot for this approach to get the terminology right and to distinguish between "literal list" (notation) and "list assign" ( like returning multiple values on the stack).

        Would help a lot if we could clean up terminology.

        Cheers Rolf

        (addicted to the Perl Programming Language)

        Thanks too, I see definitely clarity ahead. The last mile to understanding lists and why there is no dedicated operator to impose list context I will go on my own, since I do not want to suggest newbies, by defending and provoking confusion, more weirdness in the internals of my beloved Perl than there probably is. When I feel the need to impose list context explicitly, I'll consider first wantarray and take one of the expressions in the thread and add a comment on why.

        Thanks a lot for your time and wisdom,
        -- flowdy

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1089965]
Jar. Jar!...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2018-05-21 13:49 GMT
Find Nodes?
    Voting Booth?