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];
@b[0]++;
say "@a @b"; # 1 2 2 2
$ perl -e 'print ++([1,2]->[1])'
3
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....
-David
