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!!!!
pgpkL3zKnNBEK.pgp
Description: PGP signature
