As much as I don't want to refute my own operator, I agree with you here. I don't know what the "official" (this week) policy is, but I think it's a bad idea for references to auto-dereference. The other way around is fine, though (arrays auto-referencizing).
I'm pretty darn sure they autodereference... we last talked about this when we were trying to determine how an arrayref would behave when interpolated into a string literal (answer: just like the original array would).
Here's the relevant message:
On Fri, Dec 06, 2002, Larry Wall wrote:
<snip>On Fri, Dec 06, 2002, Dan Sugalski wrote: : If an aggregate and a reference to an aggregate are going to behave : the same, which is what Larry's indicated in the past, then : stringifying a reference should be the same as stringifying its : referent.
This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context.
But it's probably fair to say that $foo and @foo always behave identically in a scalar context.
So I *really* don't think comparing the equality of references will be a good idea, in P6. :-)
John Williams wrote:
You're right, but personally, I have come to trust eq more that == when comparing things-which-might-not-be-numbers, such as references.
[EMAIL PROTECTED] eq [EMAIL PROTECTED]; # true, for the reason I think # (the string-representation of the refs are equal)
I'm pretty sure that breaks too, for the same reason. It puts both sides in string context, which causes both sides to return the string representation of the underlying array, _not_ the string representation of the references themselves.
MikeL
