JT Smith

I think I mentioned the drawbacks to your case in Rethinking smart matching. You don't know what's going to happen in that smartmatch until you actually get there and know what sort of values are in scalar and array. It might never do a string comparison.

Here's an example of a failure using the type of check you showed.

my $scalar = "1welp";

my @array = (1, "foo");

print "smartmatch is broken\n" if ($scalar ~~ @array);

sub contains { my $str = shift; $str eq $_ and return 1 for @_; !1 }

And then:

if ( contains $scalar, @array ) { ... }

Now your code is about as readable as it is with “smart” match. But now it’s predictable as well, something that cannot be said of a 27-way recursive runtime dispatch by operand type.

I'm with you JT. Graham's example just looks like a bug to me.

[cibola:~] cat >t.pl
use 5.14.0;
use Scalar::Util 'looks_like_number';
say looks_like_number "1welp" ? '==' : 'eq';
[cibola:~] perl t.pl
eq

Let's just fix the bugs. It's not like we don't have the technology.

Numeric comparison is done not because "1welp" looks like a number (it doesn't), but because 1 *is* a number, and therefore this rule is followed in the smartmatch dispatch table:

Left Right Description and pseudocode
===============================================================
Any Num numeric equality
like: Any == Num

The overarching point here, that this example demonstrates, is that ~~ does *not* do what you intuitively think it ought to do.

The problem is "just fix the bugs" will break things that rely on the currently documented behaviour.

Also, making it pluggable had allllll sorts of fun scoping issues, and nobody was able to find a sufficiently sane approach to dealing with that.

So, basically, other than "kill it, wait a couple years, bring it back", there's not really a good option here.

-- mst

> Numeric comparison is done not because "1welp" looks like a number (it doesn't), but because 1 *is* a number, ...

So change that. Both sides have to look like a number in order for == to apply.

But I feel like we're getting caught up too much in nitpicky details. I believe that the anti-smartmatch lobby's point is that smartmatch simply can't be fixed. (As opposed to, say, it's too much trouble to fix, or we could fix it but that would break backward compatibility too much.) I was just pointing out that Graham's example doesn't demonstrate anything that can't be fixed.

But perhaps I've misunderstood the point, in which case I apologize for my density. :-)

If somebody can figure out a way to do pluggable ~~ that isn't even more confusing than what we currently have, the future is filled with possibilities.

So far, nobody has, so the status quo remains.

-- mst

if( $scalar ~~ @array ) { }

You're missing at least one line:

use experimental qw(smartmatch);

at which point you might as well use something more predictable, such as the contains() example above, or elem() from Data::Munge:


use Data::Munge qw(elem);
if(elem $scalar, \@array) { }


(this would also have the advantage that you don't need to add a comment explaining which of the many smartmatch behaviours was actually intended...)

Smartmatch behaviour has already changed at least once: 5.10.1 broke existing code, including the common case of "is $scalar in @array". Changing it again is unlikely to be successful without consensus as to the expected functionality - do you just want a "string in array" check?

If you can put together a proposal for how a smartmatching operator should work, that'd likely be a worthy discussion for the perl5.porters list. It'd need to be a bit more concrete than "fix the bugs" though ;)

I agree with all the criticisms of smartmatch, but I still believe that "is-an-element-of" is a very frequent operation and would be useful as an operator on its own, without the multiplicity of possibilities in smartmatch.

At the moment, with List::MoreUtils you can do "any { $x eq $_ } @y", and there's some notion that in the future junctions would let you do things like "any(@y) eq $x" (and, incidentally, "any(@a) eq any(@b)" which would be cool). But while these are more flexible features, I think they're not that easy to understand at first glance

The "contains" sub is what I use at the moment (although I call mine "in"). But I think an operator would be more comprehensible. Something like "$a in @b" (stringwise comparison) or "$a ~> @b" (numeric comparison) would be easier to understand and much simpler to use for this common case.

"any damn fool can see that it’s 2 lines of code instead of 2 characters."

That's, for me, the worst possible reason to make a syntax change. Typing is cheap, and while I prefer a good, perlish expression over a verbose, redundant one. I'd prefer typing two lines if that makes the code definite for both the maintainer and the machine.

"It’s not more readable."

yes it is. the use of List::MoreUtils points to a specific module API, and the use of eq means string comparison. Match that (no pun intended) with a maintainer needing to parse through all the smartmatch cases to figure out what is going on, or what may be happening in that line.

Perl6::Junction seems to address the "basic use cases" pretty well and readably, for a modest increase in typing effort.

It allows you to mix junctions, although you have to be careful of what you want. It also seems to be aware that equality isn't commutative any more when you mix all and any (as in all items here have to be equal to at least one item there, that is different from any item here has to be equal to all items there).

If you're worried by the Perl6:: in the name, Stevan Little's has got you covered: This is a solid module which you can use right now in your Perl 5 code..

Actually, there's already Syntax::Keyword::Junction which is a cleaned up fork that's explicitly extant to avoid the Perl6:: thing (and is maintained by the usual suspects).

-- mst

Also note that the 'any', 'all', 'notall', and 'none' interfaces are now in List::Util, which is shipped with core perl. (You should depend on version 1.33 to ensure you get an upgraded version on earlier perls that shipped an older version.)

Didn't know about Syntax::Keyword::Junction, that's what you get when you stop to the first module that fits the requirements :). It would be good to have some hint in the Perl6::Junctions docs, anyway, because it seems "more popular" with two reviews and a few more ++'s. Maybe even a new comment would do the trick?

The new subs in List::Util are OK but they (understandably) follow the syntax of the rest, which is less sugary. This seemed to be an important point in the OP. How much sugar you like is a matter of taste, of course.

I agree with Graham Knop and I consider any(@a) eq $x better because I can also say any(@a) == $x and any(@a) =~ $x, which is needed in Perl5 to avoid all smart match hoop jumping. Sometimes DWIM just expands to Detail What It Means.