Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

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.


In reply to Re^5: Bring back the smartmatch operator (but with sane semantics this time)! by davido
in thread Bring back the smartmatch operator (but with sane semantics this time)! by smls

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others avoiding work at the Monastery: (4)
    As of 2021-01-20 06:40 GMT
    Find Nodes?
      Voting Booth?