On Tue, Aug 23, 2005 at 16:32:37 -0700, Larry Wall wrote: > Hmm, well, I don't think >>&op<< is valid syntax, but you did say > "semantics", so I can't criticize that part. :-)
What is >><<, btw? Is it &circumfix:{'>>','<<'} (Code &op --> Code); # takes some code, returns a listop or &precircumfix:{'>>','<<'} (Code &op, [EMAIL PROTECTED] --> List); > I don't know how close ~~ and eqv will end up. There are some > differences in emphasis, and when two operators get too much like each > other, I tend to add more differences to make them inhabit different > parts of the solution space. One current difference is that, despite > the symmetry of ~~, it's not actually a symmetrical operator much of > the time, such as when matching values to rules. ~~ is intended to > be heavily dwimmical, so it's allowed to do various kinds of abstract > coercions to figure out some mystical "good enough" quotient. But eqv > on the other hand should probably be false in asymmetrical situations. > The implementation of ~~ may delegate to eqv in certain symmetrical > situations, of course. Right... Magic is defined in the "base" definitions of ~~: &infix:<~~> ($x, Rule $r) { ... } &infix:<~~> ($x, Code &test) { code($x) } And so on and so forth, and then it is extended by the extender to make cool aggregate operations, but even this doesn't have to be the same for ~~ and eqv, it's just that eqv should have good builtins for collections, is all. > should say "true", since those are the same values, and they can't > change. However, in Perl-5-Think, [1,2,3] produces mutable arrays, > so unless we come up with some kind of fancy COW for [1,2,3] to be > considered immutable until someone, er, mutes it, I think eqv would > have to return false, and consider two such objects to be different > values (potentially different if not actually different). Well, when I use it as if (@array eqv [1, 2, 3]) { } I think it's obvious that I'm checking "what is the value right now", and ditto when I say my $str = "foo"; $hash{$str} = 1; $str ~= "bar"; $hash{$str}; # not the same Arguably use of an array as a hash key is using a reference to a container, and use of a scalar as a hash key is using the value inside a container, so in a sense the hash key didn't change when I appended the string, but this distinction is subtle and mostly an implementation detail. > It would be possible to declare %hash some way that forces a "snapshot" > via some kind of serialization or other, but then it gets hard to keep > the identity around. Then the question arises how we doctor > > if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" } eqvs! it pronounces very well: 'eekyoovies'. Try it: if 1 2 3 eekyooviesses 1 2 3 say true, otherwise say false It's fun, but I hate it even more than eqv ;-) > to do the same snapshot comparison. Arguably ~~ could do it, since it's > explicitly *not* about identity. > > if [1,2,3] ~~ [1,2,3] { say "true" } else { say "false" } But ~~ is not "is the same" it's "matches". This is also true, and not what I want eqv for: if [1, 2, 3] ~~ [code { 1 }, rx/\d+/, Num] { say "true" } else { say "false" } > Or we could have a more explicit way of doing whatever it is that the > snapshot hash does to each argument. > > if [1,2,3].snap eqv [1,2,3].snap { say "true" } else { say "false" } I think the opposite is better, make snapshotting by default, and mutable value equality false by saying [1, 2, 3] eqv [1, 2, 3] :always # or :forever -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah!!!!
pgpqB6BHxX5TY.pgp
Description: PGP signature