|Welcome to the Monastery|
Bring back the smartmatch operator (but with sane semantics this time)!by smls (Friar)
|on Jun 10, 2014 at 16:52 UTC||Need Help??|
No I'm not kidding, please hear me out... :)
History of smartmatch in Perl
Smartmatching was invented for Perl 6 where it turned out to be a very useful and well-loved1 feature, but the attempt to backport it to Perl 5.10 in 2009 did not turn out so great (and it was consequently deprecated again in Perl 5.18). Among the Perl 6 community the commonly accepted explanation for that is, from what I heard:
These limitations are hard to circumvent, but I don't think that means Perl should have no smartmatching at all, it just means it should have less ambitious / more focused smartmatching.
I wasn't around at the time, but it looks to me as if the Perl 5.10+ smartmatching was designed with these goals:
...and was thus doomed to failure.
Some later proposals for re-designing the smartmatch operator (like this 2011 post by brian d foy) tend to avoid mistake no. 1, but still fall into the second trap.
If there are comparison/searching operations that are deemed worthy of being added to Perl (say, "deep comparison" of two arrays, or checking whether an array contains a given scalar), then each of them should get its own operator. That's the normal Perl way: One operator per type of operation (that's why we have both == and eq for example).
How smartmatch should be designed
Smartmatching explicitly breaks with the conventional "one meaning per operator" rule by dynamically deciding what operation to perform based on its arguments. This means it should be carefully designed around use-cases where you actually need to dynamically decide what operation to perform. Operations that you would likely never want to mix-and-match, have no business being part of the smartmatch operator, even if they would be useful to have in core by themselves.
So, what are those use-cases where you actually need dynamic smartmatching? I can think of two major ones:
We can make new Perl 5 smartmatching rules useful for those use-cases, while still keeping them sane and predictable, by adhering to the these two principles:
Sensible smartmatch rules
With that in mind, we can start to think about the kind of right-hand-side "things" that it should be possible to smartmatch against.
The following are no-brainers imo:
The 'simple scalar' case is not as elegant as one might wish it to be; Ideally it would be able to dynamically decide between string or numeric comparison like it does in Perl 6, but I don't think that is possible to do safely in Perl (its type system being what it is), so we need to take what we can get.
The following two rules also tend to be pretty useful in Perl 6, and it might make sense to add them to our hypothetical new Perl smartmatch, but I'm unsure about them because range literals and typename barewords are not usually treated as first-class "things" in Perl, so it might feel strange:
Lastly, the lack of junctions in Perl could be partially remedied by interpreting an array/list on the right-hand-side like an any() junction:
Of course, a better solution would be to add junctions to Perl together with re-adding smartmatch... :)
Anyway, the above rules would be more or less a subset of both Perl 6 smartmatching and the deprecated Perl 5.10+ smartmatching, but without the craziness of the latter.
And that's it; All cases not handled by these rules should generate a runtime error.
PS: In case you want to get a "feel" for what this kind of smart-matching is like in practice, check out Toby Inkster's match::simple module which implements very similar rules to what is discussed here (but suffers from some unavoidable limitations due to the fact that it is not in core).
---1) Among the small but passionate fan base of Perl 6 :)
2) This particular junction is in fact used as the default when the 'test' argument is omitted.