develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
David Golden
August 23, 2012 14:31
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Thu, Aug 23, 2012 at 3:50 PM, Leon Timmermans <> wrote:

    > You're proposing that:
    >     any(9,10,11) ~~ \&is_prime
    > be equivalent to:
    >    is_prime(any(9,10,11))
    > but what if I want it to mean what it's supposed to mean:
    >    any(is_prime(9), is_prime(10), is_prime(11))

    If «is_prime(any(9,10,11))» is not equivalent to «any(is_prime(9),
    is_prime(10), is_prime(11))», it's not a junction in the first place.

I think you're actually in violent agreement.  :-)

My view: overloading should take precedence over all other match types
because an object might need to present itself differently depending on
what's on the right hand side and thus needs to be able to supersede other

Stepping back -- look at what 'perldoc overload says':

    How Perl Chooses an Operator Implementation

    Which is checked first, "nomethod" or "fallback"?  If the two
    operands of an operator are of different types and both overload
    the operator, which implementation is used?  The following are
    the precedence rules:

    1.  If the first operand has declared a subroutine to overload
    the operator then use that implementation.

    2.  Otherwise, if fallback is TRUE or undefined for the first
    operand then see if the rules for autogeneration allows another
    of its operators to be used instead.

    3.  Unless the operator is an assignment ("+=", "-=", etc.),
    repeat step (1) in respect of the second operand.

    4.  Repeat Step (2) in respect of the second operand.

    5.  If the first operand has a "nomethod" method then use that.

    6.  If the second operand has a "nomethod" method then use that.

    7.  If "fallback" is TRUE for both operands then perform the
    usual operation for the operator, treating the operands as
    numbers, strings, or booleans as appropriate for the operator
    (see note).

    8.  Nothing worked - die.

    Where there is only one operand (or only one operand with
    overloading) the checks in respect of the other operand above are

    There are exceptions to the above rules for dereference
    operations (which, if Step 1 fails, always fall back to the
    normal, built-in implementations - see Dereferencing), and for
    "~~" (which has its own set of rules - see "Matching" under
    "Overloadable Operations" above).

What we're talking about is removing the special case for ~~ and making it
work just like other operators.  Since smartmatch has no autogenerated
fallback and is not an assignment, the table above collapses to something
essentially similar to what Damian described *except* that he suggests
making right side overloading take precedence over the left side.

And to that -- why? Should it be completely consistent instead, where
overloading on the value being tested (left side) takes precedence over
overloading on the comparison value (right side)?

Presumably, overloading on the value would be due to it replacing the
object with a different value to actually compare and would then smartmatch
on the replacement value against the original comparator -- which would
then trigger the overloading on the comparator and do the right thing.

On the contrary, overloading on the comparator might result in a different,
non-smartmatch comparison being performed.  That might trigger different
overloading on the value (e.g. "eq" or "=="), but would bypass smartmatch
overloading.  That seems likely to lead to bugs by incautious overloaders.

Removing special cases is *good*.  Let's make smartmatch overloading work
just like other operators.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About