Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re^2: Bring back the smartmatch operator (but with sane semantics this time)!

by smls (Friar)
on Jun 10, 2014 at 22:17 UTC ( #1089460=note: print w/replies, xml ) Need Help??

in reply to Re: Bring back the smartmatch operator (but with sane semantics this time)!
in thread Bring back the smartmatch operator (but with sane semantics this time)!

One thing that will surprise people is that it contains no provision for numeric comparison, so by the numeric/string duality, numbers will be compared as strings.

Yes, I agree that this is the biggest weakness of the suggested rules.

The problem of surprise could be partially mitigated by emitting a warning when a numeric literal is used as the RHS of a smartmatch (or as a when-expression), but of course numbers coming in through variables would still silently use string comparison.

As for there being no way to employ numeric comparison, in theory people could create a Num class that overloads ~~ and forces numeric comparison, but such a solution likely won't be worth it to users of smartmatch or given/when (since the whole point of those features is to make things simpler).
So I guess the case of numeric comparisons simply won't be covered, or rather, people will be forced to write it out verbosely:

given ($_ == 5) { ... } $foo ~~ sub { shift == 5 }

Not ideal, but also not necessarily a deal-breaker.

Of course, I would love to be proved wrong regarding separate string/number dispatch not being possible to do safely in Perl... :)

I have my doubts about the cases you're not sure about; distinguishing barewords from strings is impossible in non-strict mode (which I rarely use, but which is still a big part of perl, whether you like it or not).

Ranges become flipflops in scalar context and a list in list context, so doing a range comparison seems pretty much inconsistent with the rest of the language.

Comparing lists with any-semantics requires the right-hand side of the ~~ to be evaluated in list context, which IMHO would be a bit surprising.

All good points. I guess it's better to leave those rules out then.

As for junction semantics, it occurred to me that the problems/warts of the existing Junction module(s) on CPAN would probably go away once ~~ like described above (but without the three "bonus" rules) is in core and those classes have been updated to overload it (rather than relying on hacks like overloading == for non-standard things.

So, support for  $topic ~~ any('foo', 'bar', qr/baz/)  would then be provided by those modules and would not need to be hacked into the smartmatch operator itself.

And if, at a later time, one of those junction modules makes it into core too, then all the better.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1089460]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2020-07-08 04:50 GMT
Find Nodes?
    Voting Booth?

    No recent polls found