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

Re: Revisiting smart match

Thread Previous | Thread Next
From:
Zefram
Date:
August 2, 2017 11:32
Subject:
Re: Revisiting smart match
Message ID:
20170802113213.GA31972@fysh.org
I wrote:
>    0: RHS overloading

Additional detail: the overloaded method should always be called in
scalar context, and its return value should be converted to a canonical
truth value before being yielded by the ~~ operator.  (The latter step
potentially being skippable if it can be proved that an SvTRUE() is
coming up anyway, a la DaveM's recent optimisations.)  This is because
the concept of smartmatch is fundamentally a predicate operator, like
exists() which similarly canonicalises the result of a tied EXISTS method.

The same goes for calling a callable, if we go with a rule for doing
that with a callable on the RHS.  Current behaviour, for both overloading
and calling, is to call in scalar context but not canonicalise the result.

Another train of thought: with this kind of very short list of matching
rules, use of smartmatch will be relying very heavily on the overloading,
because that's the only way to get any interesting matching behaviour.
Someone's bound to complain about the relative expense of making a sub
call to an overloaded method for all sorts of otherwise-cheap comparisons
that could have been built into a long list of matching rules.  But this
is optimisable.  By op hackery, many classes of smartmatcher can arrange
for their construction to be constant folded.  By more op hackery,
the class can also inline matching against the resulting constant
smartmatcher.  This would probably become moderately common, to the point
that we'd invent a generic mechanism for a class to declare a match-check
function, in the same way that a sub can declare a call-check function.

>    2 (optional): plain string (defined, non-glob, non-regexp, non-ref
>       scalar) on the RHS: $lhs eq $rhs

I'm vacillating on whether this ought to also include a condition that
the LHS is a plain string.  On the one hand, we don't usually apply such
conditions in core operators.  On the other hand, this rule does involve
applying such a condition on the RHS.

-zefram

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About