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

[davido]

I mentioned this in another deeper-level followup in this thread, but I want to try to explain my position.

Perl's type system is its operators. This is why we don't have PHP's "===" and "==" operators; they try to guess at programmer's intent. Perl doesn't guess; whenever possible it reacts to known intent, which is different from guessing at intent. Our scalar containers are typeless; it's up to the programmer to decide what type to imply at any point in the program. Resorting to heuristics to decide what type a container may be is pointless; containers in Perl are typeless. What has to happen, is operators have to know how to provide a type context.

Smartmatch works fine in a language whether containers have type, and operators react to the type. It doesn't work well in a language where containers don't have type, and operators specify the type. It ends up either having a huge list of rules and heuristics that people have to consult the manual to recall, or a small set of rules and heuristics that reduces its value while still leading to less clear code than the type-specifying operators.

In short, Perl operators are chosen by programmers to impose type. Perl reacts by providing the correct type to the operators. If you try to invert that paradigm in a language where containers have no type, you end up with messy heuristics or complex rules, or incomplete operator implementations (as in a reduced-functionality smartmatch)

[tye]

Perl has fairly clear types like "scalar", "array", and "hash", so it could be useful for smart match to do different things when given an array or an array ref compared to when given a non-reference scalar. But even that case is not 100% clean (mostly due to overloading where you can have an object implemented as a reference to a hash that wants to behave like a scalar string or like a reference to a virtual array or such).

But you are very right when it comes to trying to distinguish between "number" and "string".

Smart match only looking at the "type" of one argument can improve the problem significantly. So I could see "when( 14 )" noticing that a literal number was given in the source code and so a numeric comparison should be used. But that clean line quickly becomes muddier in the face of code refactoring to things like "my $const = 14; ... when( $const )".

You either let that level of refactoring break smart match or you don't let smart match try to distinguish between strings and numbers (or else you doom smart match).

The only 100% clean case is having "when( @array )" behave differently than "when( $scalar )" (and similar).