in reply to Re^11: If you believe in Lists in Scalar Context, Clap your Hands
in thread If you believe in Lists in Scalar Context, Clap your Hands

If JavaFan said that lists don't even exist, that I don't agree with him. I suspect that's not what he meant, though.
What I said is that Perl doesn't know about lists. A list is not a Perl datastructure. Lists don't have names. Once the program is compiled, "lists" are just a bunch of scalars on the stack. In the same way that Perl doesn't really know about string literals. Once the program is compiled, a string literal is a value. Note also that I made the remark in response to a request for clearification about the difference arrays and lists. Arrays are first class objects. They (can) have names. They have their own datastructure. They can be referenced. Lists have none of that; they aren't even second class objects.

That of course doesn't mean that humans can't talk about lists. Just as humans can talk about object attributes - Perl wouldn't know what an object attribute is.

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

Replies are listed 'Best First'.
Re^13: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief (Monsignor) on Oct 29, 2008 at 14:50 UTC
    What constitutes a "first-class object" tends to vary by language. Strictly speaking in generic inter-language terminology, arrays and hashes in Perl are not first-class objects by many definitions. One cannot pass a hash or array into a function intact. One cannot return a hash or an array from a function, or assign one hash or array directly to another. Without library support (DBM::Deep or such) the values are what gets copied (with a hash key being a special type of "value" that is the key to another value).

    The only first-class objects in a very strict sense of which I can think right now in Perl are scalars, references, typeglobs, and perhaps (classic, blessed reference to something) object instances. I hesitate to include object instances since they are "just blessed references", but when returned or assigned they do carry their class information and instance information with them at the language level.

[reply]
      One cannot pass a hash or array into a function intact.

      If that were true, push wouldn't work, and you couldn't override CORE::push. You're confusing pass by value/reference with first-classness.

[reply]
[d/l]
        What happens there is a clever trick of prototypes in Perl 5. It doesn't pass a variable by reference, but passes a reference to the variable that was an argument. There is a difference. It also sidesteps the fact that any aggregate object passed into a subroutine by the default call-by-value would otherwise be flattened to a list. This flattening by the default variable passing mechanism is evidence against calling Perl aggregates first-class objects.

        If what happened was really "pass by reference" in a classical sense, one would be able to operate on the passed variable by the lexical or localized variable's name without regard for the reference, only it would effect the original. That's not what happens. You can force the subroutine, via the prototype mechanism, to take a reference to the argument but you still have to treat it as a reference. 

        sub foo (\@) {
    print pop @{$_[0]};
};
@bar = qw( foo bar );

foo @bar;

        [download]

        BTW, lists are not precluded from being first-class simply by not being named, either, as JavaFan pointed out as a disqualification earlier. Anonymous lists, anonymous functions, and anonymous closures are first-class objects in some languages.

        As I said before, what constitutes a first-class value can vary by language. In Perl, one could consider arrays and hashes as first-class, but one could make arguments against that classification as well.

[reply]
[d/l]

In Section Meditations