develooper Front page | perl.perl6.language | Postings from August 2006

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

Thread Previous | Thread Next
David Green
August 13, 2006 12:51
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Message ID:
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])'

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]]?

$a=\@a should be different from (!===) $b=\@b 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 $b=\@b and I do $b[0]++?  It 
might look superficially as though I were changing $b, but $b still 
is \@b -- @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....


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About