On Wed, Sep 21, 2005 at 13:53:20 +0200, TSa wrote: > HaloO Yuval, > > you wrote: > >On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote: > >> role Object does Compare[Object, =:=] > >> role Num does Compare[Num, ==] > >> role Str does Compare[Str, eq] > >What is the implication of from the perspective of the person using > >Object, Num and Str? > >Do they have one unified comparator? > > No, the role installs homogenious targets into the generic > binary-MMD comparator which I think is called eqv.
Err, why? We already have that with regular MMD semantics.
role Num {
multi &*infix:<eqv> ($x:, Num $y) { $x == $y }
}
> That's an interesting question which is related to my retention to metric
> MMD. We must distinguish homogenous from heterogenous comparisons. My
> role Compare from above ensures that the comparor can be deduced from the
> unique (super)type of the two values to be compared. As such the comparator
> indirectly is class or type specific. The heterogenous cases however have to
> fallback to "real" MMD. Now metric MMD could spoils this approach by picking
> the "wrong" eqv target even though a proper homogenous target were
> available!
Then MMD must be fixed, as I've argued several times before.
MMD cannot work unless it does what almost everyone means and
complains when there is no obvious way.
What you're describing is a problem that a broken (by this
definition) MMD system can provide.
> I'm not sure if I get you right, but I think we agree that
> there should be only one comparer for a certain type/class.
> Everything else is nonsense. I mean apples should know how
> to eqv to other apples and oranges with oranges. MMD enters
> the picture only if you want to compare apples with oranges.
> By color, by weight, as fruits in general, etc.
Comparing apples with oranges should do two equivalent MMD lookups
on coercion, one of apples to oranges, the other of oranges to
apples (unless there is an MMD compare between apples and oranges
already), and if they are equivalent then there is an error.
> It seems that the Code type is still some kind of second class
> citizen in Perl6 because you can't nicely apply prefix ops to
> pending invocations without some help from the meta categories.
> And I'm unsure if
>
> $x (+&eqv)() $y
>
> works even when prefix:<+>:(Comparor) exists and returns a
> numeric Comparor. But named params next to the operator could work
I think it should even without the parens... isn't the & sigil
enough to make it clear? & is just like $ in this respect
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!
pgpihNFvtu8Pt.pgp
Description: PGP signature
