Front page | perl.perl6.language |
Postings from September 2005
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!Thread Previous | Thread Next