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

Re: Revisiting smart match

Thread Previous | Thread Next
August 1, 2017 22:47
Re: Revisiting smart match
Message ID:
Father Chrysostomos wrote:
>I think we need item 2.  There will be too much grief without it.  I do
>agree on making no distinction between numbers and strings.

FWIW, I also had a thought about a completely different matching rule for
plain strings: defined(Scalar::Util::blessed($lhs)) && $lhs->isa($rhs).
This would be playing to the idea that smartmatch tacitly defines
the type system that the core has hitherto lacked.  (If we want type
constraints on core signatures, for example, the clean way would be for
the signature to include expressions that evaluate to smartmatchers.)
But I don't mind punting class membership checks to MooseX::Types-like
metaobjects that overload smartmatch.

My thought in marking the plain string rule as optional is mainly due
to the potential confusion with numbers.  Whatever we do, some people
will expect numeric matching with ==.  We can't have a separate rule for
that because numbers are also strings.  But having string matching at
all is then an attractive nuisance for the numeric crowd: code written
expecting numeric comparison will *usually* produce the expected answer
via stringification.  I think that's a tolerable downside, but if it
were to become a subject of significant debate then I'd rather give up
string matching than put much effort into defending the eq-only rule.
It would certainly be better to lose string matching than to end up with
a fudge of separate numeric and string matching rules.

>Alternatively, we could add &{} overloading to the Regexp package (which
>would be a useful thing regardless of smartmatch),

Even if we very much want to have a smartmatching rule for callables,
I don't see any gain in the Regexp class overloading call rather than
overloading smartmatch.  I'm also dubious about a call override on Regexp
being useful in its own right, especially if smartmatch exists.

As for callables as smartmatchers per se, as I noted, there's some
conflict with smartmatch overloading.  Only a bit of conflict when
thinking about actual CVs, but an object that overloads call could very
easily overload smartmatch too.  I'd rather avoid the conflict entirely.
Where we have an actual CV and want to use it as a smartmatcher, it's
not very onerous to bless it into a class that overloads smartmatch and
implements that by a call.

>This came up before.  The previous proposal was to keep smartmatch for
>when(){}, and to disable it for when{}{} (with a true block for the

To "keep" what, exactly?  What we have now for when() is not consistent
use of smartmatch, it's inconsistent.  I'm not wedded to the particular
assignment of bracket types to semantics (though I like the consistency
of my suggestion with if()), but I do think that each semantic on offer
ought to be consistent in how it treats any expression.  We should not
keep the existing rule, under any syntax.

>The one issue that never got resolved before (and which ultimately
>derailed the overhaul attempt) was how to deal with 'break' and
>'continue' semantics.

Intellectually it doesn't seem necessary to treat all of this as a single
experimental feature, though the warning categories currently have it
that way.

But amusingly "break" and "continue" don't generate experiment warnings,
and (like last et al) they're resolved dynamically.  So "use feature
'switch'; sub foo { break; }" compiles and ostensibly does not invoke
experimental behaviour.  (Unlike last et al, there isn't even a warning
for exiting a subroutine that way.)  To make significant use of that sub
some other code would have to use "given" or "when", which does yield an
experiment warning.  But code that just invokes "break" without using
"given" or "when" gets no experiment warning and gets behaviour that's
quite different from your proposal of it being synonymous with "last".
That might limit your options in redefining these keywords.


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