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.
If so, this sounds like you are subverting MMD with some odd
currying of the 'compare' method (whatever it's name may be)
provided by the Compare role, instead of relying on the already
existing semantics of MMD dispatch to give you the same name for
several, superficially same meanings.
The problem with equality checking is that there are several
notions of equality :) And if you include them into the set of
types used in the dispatch decision you end up with the very
unspecific :( ::X, ::Y, Code.does(Compare) --> bool ) type and
the difficulty of defining a nice call syntax for it!
The driving idea here is that the syntactical choice of the programmer
amounts to a type preference of the Comparer subtype.
Do you mean on a per class or per comparison basis?
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!
I think that exceptions from the class perspective should not be
done by parametrising the quality role, but overriding it, and that
from the per comparison perspective we need to say either:
coerce_to_other_type($value)
generic_equality
coerce_to_other_type($other_value)
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.
and being an operator rich language we can specificate the generic
comparator to make things a bit more fun like I proposed:
$x +eqv $y;
$x ~eqv $y;
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
$x eqv:num $y
and plain eqv could actually mean binary eqv:mmd on the lhs and rhs.
Ofcourse, I think that s/eqv/==/;, but everyone hates that.
Well, I wonder if ($x eqv $y) is the same as !($x xor $y) and
as such we just lack a high precedence correspondence to ^^ :)
Hmmmm, the Mathematician in me sees <==> ...
But wouldn't that mean that ^^ should be <!=> ...
--
$TSa.greeting := "HaloO"; # mind the echo!
