On Tue, Jan 27, 2009 at 10:59:34AM -0800, Jon Lang wrote:
: If there are only a handful of operators to which the new
: meta-operator can be applied, why do it as a meta-operator at all?
As a metaoperator it automatically extends to user-defined comparison
operators, but I admit that's not a strong argument. Mostly I want
to encourage the meme that you can use - to reverse a comparison
operator, even in spots where the operator is named by strings, such
as (potentially) in an OrderingPair, which currently can be written
&extract_key => &infix:<-leg>
but that might be abbreviate-able to
:extract_key<-leg>
or some such. That's not a terribly strong argument either, but
perhaps they're additive, if not addictive. :)
: This could be generalized to allow any infix operator returning a
: signed type (which would include C<Order>) to reverse the sign. In
: effect, "$x -op $y" would be equivalent to "-($x op $y)". (Which
: suggests the possibility of a more generalized rule about creating
: "composite operators" by applying prefix or postfix operators to infix
: operators in an analogous manner; but that way probably lies madness.)
Well, even -+ seems a bit mad. And Int/Num don't do Order, since that's
an enum subset of Int, not a role.
: Also, wouldn't the longest-token rule cause C<-=> to take precedence
: over C<=> prefixed with C<->? Or, in the original definition, the
: fact that C<=> isn't a comparison operator?
It would be a tie, since both operators are the same length. The
current tiebreaking rules would make it depend on which was declared
first, which may or may not make sense. Arguably autogenerated
operators should give way to hardwired ones, much like foo\w* gives way
to foobar currently.
Larry
