Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

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

by RonW (Vicar)
on Jun 11, 2014 at 16:57 UTC ( #1089561=note: print w/replies, xml ) Need Help??

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

If Perl, itself, does not internally know a value is a number, how can it convert a number to a string?

Looking at Mojo::JSON and JSON::Tiny, they both seem to be "pure Perl" implementations, so they would have to use heuristics.

Looking at perlapi:

SvNIOK "Returns a U32 value indicating whether the SV contains a number, integer or double."

So, it seems that, internally, Perl knows if a scalar is a number.

  • Comment on Re^4: Bring back the smartmatch operator (but with sane semantics this time)!
  • Download Code

Replies are listed 'Best First'.
Re^5: Bring back the smartmatch operator (but with sane semantics this time)!
by davido (Archbishop) on Jun 11, 2014 at 17:23 UTC

    They do use some B:: trickery, but it's minimal. And the fact is "has it ever been used as xyz before?" is a terrible heuristic. Unfortunately, it's just about the only heuristic available. I love Perl's malleability, but this is one area where it hurts us.

    Internally Perl can store a value that looks to us like a number as an IV/NV (integer/numeric value), or a PV (pointer to a string), or frequently both. This rarely matters to the end user, because numeric operations will autovivify a numeric component, string operations will autovivify a string component, and there's very little ambiguity involved. '==' is always for numeric comparisons. 'eq' is always for string comparisons, and so on. It's generally not necessary for the end user to care about internal representation.

    This all changes for JSON, because JSON does care whether an entity is a number or a string. There's no JSON generic "scalar" as we have in Perl. This is essentially a type mismatch between Perl's "scalars" and JSON's representation of data. People writing and maintaining JSON modules seem to continually struggle with providing a solution that will present the least amount of surprise to end users. At what point should a scalar be mapped to a string for serialization? At what point should it be mapped to a numeric value? It's not an easy question to answer, and that's why you've seen the solution evolve.

    Smartmatch is another example of where the implementation detail necessarily leaks out of the internals to the user. What should "scalar ~~ string" do? What should "scalar ~~ num" do? Should all such matches occur in string context, as though the user had simply used eq? If so, why isn't the user just using eq in the first place? Why should ~~ "smartly" coerce string context to act like eq, but not smartly handle numeric context? (one reason is the JSON problem.)

    The fact that the proposal treats all scalar to scalar comparisons as eq is an example of the whole smartmatch shortcoming. It's supposed to be smart, after all. But as soon as we start trying to make it smart, we end up with a zillion special case rules, and users have to consult a manual every time they try to use it; it's too smart. So we dumb it down to a few simple rules, and then the rules make using it dumb, since we may as well have just used the proper operator in the first place.

    Perl's operators are type specific in a type-free system. The operators are our type system. There is no meta-information inherent in our scalars to tell us they're ints, strings, or floats, because that distinction is totally dynamic, and totally up to the programmer at any given stage in the program's execution. It's the programmer's decision to use '==' or 'eq', for example. If we wanted Perl to try to guess, Perl would have overloaded '+' for concatenation. Languages that go down that road end up with "==" and "===" to provide imprecise hints, and it usually ends in naive misuse and bugs (I would guess that 50% of the PHP code in the wild misuses == and ===).

    Because our operators are how we impose typing on our typeless variables, it becomes highly problematic when we try to invent operators that guess at our meaning in the absence of reliable meta-data. Smartmatch is fine in a language where containers have types. It's madness in a language where operators have types and containers don't.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1089561]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2017-07-26 21:46 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (402 votes). Check out past polls.