Way back on 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:19:24PM -0600, David Green wrote:

No, === is also deep.  It's only shallower (or potentially shallower)
in the sense that it treats any mutable object node as a leaf node
rather than changing to "snapshot" semantics like eqv does.

Yup, which it would have to be even given the slightly-off way I was thinking of it. So I've quietly snipped the part where I said it wasn't and will pretend it was never there.

: (One [1,2] is as good as any other [1,2] -- what's the use of ever
: having them not compared as the same?  I can see maybe for =:=, since
: something that doesn't have a name cannot, by definition, have the
: same name as something else... although even there, it arguably makes
: sense to consider equivalent anonymous values as "bound" to the same
: place.  There's only one unique [1,2] in platonic heaven, I'm just
: mentioning it directly instead of dropping a name.)

On the contrary, there isn't one single platonic [1,2], since square
brackets construct a mutable Array object:
    @a := [1,2];
    @b := [1,2];
    say "@a @b";      # 1 2 2 2

$ perl -e 'print ++([1,2]->[1])'

Hmm... well, I guess I shouldn't be surprised that that worked, it makes sense -- you can't have an array-ref unless it refers to something. But something still bothers me... Perl knows that my anonymous array-ref is pointing at something, so it's [effectively] got some kind of "internal" name that it knows about, but I don't. So it isn't really anonymous... it's a Rumpelstiltskin array!

I guess my problem is that [1,2] *feels* like it should === [1,2]. You can explain that there's this mutable object stuff going on, and I can follow that (sort of...), but it seems like an implementation detail leaking out. In many languages, strings are just character arrays, and presumably someone could write a version of Perl that actually built strings out of array refs, but I'd still want "foo" to === "foo".

And I feel this way because [1,2] looks like it should be platonically unique. Or at least leibnizianly unique: if two things don't have any different features, then they aren't different. And one [1,2] can do anything that another [1,2] can. ...Except have the same object ID, which doesn't seem particularly useful, except for distinguishing them, which is what I don't want to do.

Is there a useful non-implementary reason to tell them apart (excepting obfuscated P6 and stuff Damian might do), or can you just hide it?? (Ignorance is bliss for bears of little brain like me.) Some convenient skidding around to make identical array-refs look, well, the identical. Of course, when you suppress one thing, you have to start stomping down spots all over the waterbed, and eventually it might burst. Maybe I'm just not thinking about it from the right direction... Do I feel that \1 (a ref to a literal "1") should be platonic? Does it matter? As you said, ordinarily I'll be assigning rather than binding, so stuff will just work.

Can I make a nested Seq with something like (1;2; 3,4)? Compared to the nested Array referential [1,2, [3,4]]?

[EMAIL PROTECTED] should be different from (!===) [EMAIL PROTECTED] because even if @a eqv @b eqv (1,2), @b might change. But if $a=[1,2] and $b=[1,2] there's nothing I can change that will make $a and $b different, so for $a not to === $b is Fairly Surprising in Principle. That is, nothing *else* I can change, since of course changing either $a or $b will make them different.

You may tell me that $b[0]++ *is* changing something other than $b, but it sure looks like changing $b. The only way I can get at the original [1,2] is by going through $b, so I think I am changing $b. But wouldn't I think the same thing if [EMAIL PROTECTED] and I do $b[0]++? It might look superficially as though I were changing $b, but $b still is [EMAIL PROTECTED] -- @b is what's really changed. Hmmm. If Perl is simply more complex, there's no point my trying to hold a naive view.

Maybe it's one of those things that never will seem quite comfortable until I just get used to it....


Reply via email to