HaloO,
Yuval Kogman wrote:
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 }
}
What you mean is double dispatch, cascading, delegation or what ever.
I had the two juxtapositions of
$x eqv $y
versus
$x &ee $y # or even $x $ee $y when $ee is a coderef
in mind. In the latter case you a get a complicated mix of parsing that
in the first place and generating code for a three invocant anonymous
dispatch or whatever it is. I mean with *no* :<eqv> in the definition.
multi &*infix: ($lhs, Compare &comp, $rhs) {...}
BTW, is that now valid syntax? I thought there is no & sigil
but one of the two keywords sub or method:
multi sub *infix: ($lhs, Compare &comp, $rhs) {...}
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.
Sorry, I don't understand what an "MMD lookup on coercion" should be?
Do you think of eqv as a simple two parameter sub that *single* dispatches
first on the $one then on the $other arg with the respective non-invocant
as parameter and then xor's and negates the results for consistency?
sub eqv ($one, $other --> Bit)
{
# .compare_to:(Object: Object --> Bit) note the single invocant!
return !($one.compare_to($other) ^^ $other.compare_to($one));
}
Apart from the fact that somehow two types are involved I don't
see MMD in that. To me a method's name is a concept that is
realized differently for different types of arguments. At hand
we are discussion the well known problem of generic equality
versus more specific equalities of strings, numbers or objects/refs.
And now Perl6 addresses the ternary problem of remaining generic
with respect of the infix operator name or precise concept such
that it ends up comparing numbers numerically, strings textually,
colors colorfully plus all the mixed cases while at the same time
keeping compatible to Perl5's operator semantics. The first problem
you face in this quest is naming the beast---and the three letters
'eqv' aren't it to me because variable stuff in Perl is expressed
with sigils. I'm not sure if the above discribed extreme case
if $x $ee $y { say "Hurray, we have equality" }
has a chance not to end up with a 'two terms in a row' parse
error.
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
Which parens? The ones around (+&eqv) or the trailing call op ()?
Note that the precedence of postfix () is higher than prefix +.
And +&eqv might simply mean a numerified coderef and not a dispatched
call of prefix + where the returned value is type checked at runtime
for infix operator type compatibility. And then after this successfull
type check this returned operator is MM dispatched on ($x,$y).
And I can increase the challenge level easily to
my $o := &eqv; # or with \&eqv ?
if $x +$o $y {...} # parseable without type info about $o?
Just to mention one possible alternate interpretation, imagine prefix +
on $o returning a postfix op that given $x returns yet another
prefix op that given $y returns a value that is booleanized by
the if which then executes or skips the trailing block correspondingly.
That is with explicit parens we would get:
if (($x(+$o))($y)) {...} # parseable?
That is like parsing the sentence: "Time flies like an arrow",
and asking yourself: "What are time flies and why do they like arrows?"
If the above works, I guess variability against the if will not parse?
sub foo ($i, $x, $y, $z)
{
$i $x $y $z { say "something got us here" }
}
Or does it? Actually sigiling i and y with & instead of $
reduces the possibilities a lot and might even imply to
associate the trailing block literal with &i and default
&y to an infix op. Thus a call
foo( &*if, 42, &infix:<==>, 42);
will indeed say "something got us here"---that something
beeing the numeric equality of 42 and 42 :)
With some parsing magic thrown in, I would still propose to
make junctions in the style of the above foo such that
if any( $points > @highscores ) { say "a new entry!" }
means what auto-threaded ($points == any(@highscores)) means
now, but makes junctions a Code subtype syntactically. And
we code force all Code types to travel in & vars for clarity
in sigs. I mean
sub foo ($x, $y) {...}
would expell junctions while a
sub foo (&junc, $y, [EMAIL PROTECTED])
{
if junc( $x == @data ) { say "we have a numeric equality"; }
}
would allow them just as it allows a call
foo( {?$^x}, 7, 1..7 );
which prints "we have a numeric equality" if == retrieves
the size of the array. Well and
foo( &any, 7, 1,2,3 );
doesn't look like a junction in disguise.
--
$TSa.greeting := "HaloO"; # mind the echo!
