In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.

IMO its a pretty useful distinction. For instance:

my @array;
my $arrayref=[]


my @copy=@array;
my $refcopy=$arrayref;
[download]

So now what happens to the thing $arrayref references when when we modify $refcopy->[0]? It changes. What happens to @array when we modify $copy[0]. Nothing.

The point is that you can determine many things about manipulating an object by its sigil. For instance a copy of a ref is cheap, a copy of an array is not. Modifying the contents of a ref will change the results of all things using the same ref. Modifing the contents of an array will only change that array or things that reference it.

Maybe im too close to the trees but I see a big difference between them and good reasons to have both. Sure you can provide all the same effects with only references (provided you have a way to clone/copy an array) but there is a lot to be said for making them visually distinct. I mean personally i find

my @copy = @array;
[download]

my $copy=$array->copy;
[download]

In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.

IMO its a pretty useful distinction. For instance:

my @array;
my $arrayref=[]
[download]

I should probably let the perl 6 experts talk about this, but as I remember it the distinction is being downplayed somewhat for Perl 6. People need to use references so often that in Perl 6 you're going to tend to get references to things by default, rather than as a special case that you need to ask for.

as I remember it the distinction is being downplayed somewhat for Perl 6. People need to use references so often that in Perl 6 you're going to tend to get references to things by default, rather than as a special case that you need to ask for.

There is some truth in what you say, but I'm not sure it really applies in this context. Perl6 will still have the distinction between the reference and the thing being referenced. Yes, the basic shorthand dereferencing notation will dereference as many levels as necessary to get down to the referenced object (though I assume there will be a way to dereference just one level, if that's what you need to do), and yes, some builtins will handle things a bit differently, but the distinction between a reference and the thing that it references is certainly not going away. Perl6 will not be Perl5, but it will still be Perl.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

ObDisclaimer: I'm no monk, I'm relatively beginner.
I can't imagine that "my $copy=$array->copy;" is more ambiguous than "my @copy = @array;". The former is IMHO clearer conceptually, the latter is the more ambigiuous to my beginner brain. If I need to copy, I'll be glad to make it explicit with some more typing. Otherwise knowing everything is a ref "normally" would be just peachy for me.

In a language like Perl, it's not clear to me that the distinction between "array" and "array ref" is a useful one.

This is the core of the issue right here.

For example, the fact that you can return a reference to a local (er, my) variable inside a function is indicative to me that Perl doesn't seem to have the concept of auto variables.

It's indicative of the fact that Perl does have the concepts of lexical scope, anonymous objects, and, in particular, lexical closures. my variables are not local in the same sense that e.g. Inform means by "local variable". (They are closer to it than Perl's local variables, which are dynamically scoped, but that is neither here nor there ATM.) In particular, it is an easy mistake to make (and one that I made once upon a time, when I was very new to Perl) to misunderstand Perl's lexical variables, thinking either that they are persistently scoped to a given function or block ("static" in C parlance) or to go wrong in the other direction, failing to account for references and assuming immediate destruction at the end of the block. But neither of these semantics would be nearly as useful as the one Perl has (although the former could be a useful *additional* option, and I think we may be getting that in Perl6; I cannot think of any use for the latter).

Presumably the things getting placed onto the function call stack are not actual variables, but reference counting pointers

The function call stack is not part of Perl (as a language). It is part of perl (the interpreter), an implementation detail that could change between minor versions without having any significant impact on existing Perl code.

Reference counting is another matter; yes, Perl5 does reference counting. (Perl6 will have real GC, so I am told, likely of the mark-and-sweep variety.) However, that rears its head in other situations, such as when you have cyclic data structures. In the case you're talking about (assuming I correctly understand what it is you are talking about), the same thing would happen if Perl5 had mark-and-sweep garbage collection today. You can do the same thing in Scheme, for instance. If you can't do it in Python, that is because Python deliberately steers you to thinking according to the OO paradigm; Perl embraces various paradigms: OO, FP, contextual, ... this is the essential paradigmatic flexibility that makes Perl the language that it is. TMTOWTDI, and for various situations or problems one of them may be more helpful than another.

Do we really need to care about the distinction between variables and references?

Yes, absolutely -- or, at least, we have to have a distinction between references and the things that they reference. The question of what constitutes a "variable" is another whole thread, and one that I suspect would be a tangent here, not the real issue.