3 ms·

It's simply incorrect.. > Although I didn’t write any types by hand, the arguments of this function are typed. Why don’t we have to write types in ReasonML?

• koolba 7y ago
  Does ReasonML infer that a type "Product" is the only one in the visible namespace with a "name" property or does it infer at use time that the formatName(...) invocation is valid because the argument has a "name" property? They're separate concepts. Maybe I want to ensure that I'm receiving a product as it makes no sense to invoke formatName(...) on other things with names like a Cat or Person. And the generic "thing with a name" one is possible in TypeScript too: const formatName = (product: {name: string}) => "Name: " + product.name
  • dmitriid 7y ago
    IIRC if there are several possible choices, the compiler will complain (with a fairly incomprehensible message), and you will have to explicitly provide the type. And this happens all the time.
  • arthurbrown 7y ago
    They're different concepts with different ways of being expressed in OCaml. In this case it truly is a Product and if you want to reuse a field name you'll need to enclose that type in a module. Row polymorphic -- "thing with a name" -- is possible through the object system which is accessed through a different syntax, and works like go interfaces in practice.
  • masklinn 7y ago
    > Does ReasonML infer that a type "Product" is the only one in the visible namespace with a "name" property Yes. > does it infer at use time that the formatName(...) invocation is valid because the argument has a "name" property? No. OCaml does have a structural object system (https://v1.realworldocaml.org/v1/en/html/objects.html https://v1.realworldocaml.org/v1/en/html/objects.html) and it is available to reason, but it's syntactically funky (https://reasonml.github.io/docs/en/object https://reasonml.github.io/docs/en/object) and as far as I can tell TFA does not use it. > They're separate concepts. Yes. Which is why OCaml (and thus Reason) separates it[0] from the nominative "structures". > Maybe I want to ensure that I'm receiving a product as it makes no sense to invoke formatName(...) on other things with names like a Cat or Person. You're really deep into this strawmanning thing. [0] pretty completely, you can't use nominative types in a structural context, they are not compatible. In fact structural types are sets of methods, something which doesn't exist on the nominative side.
    • koolba 7y ago
      I didn’t mean it as a straw man. I’m not familiar with ReasonML at all and meant to illustrate the example.
• virtualwhys 7y ago
  Why did you stop reading? The TS version has zero type safety (compiler infers any), whereas the RML version will only accept numeric type arguments.
  • kadfak 7y ago
    In Reason let sum = (a, b) => a + b; actually accepts only arguments of type int, not any numeric type. The + operator is defined as let (+): (int, int) => int; To have the function accept floats, for example, you would have to use the +. operator like this let sum = (a, b) => a +. b;
    • mcv 7y ago
      I noticed the article had a tendency to compare numbers in Typescript with integers in ReasonML, and I was wondering why. I guess a clearer distinction between the two can be nice, but then how does that compile to javascript?
      • yawaramin 7y ago
        ReasonML ints and floats both compile to JavaScript numbers. See https://bucklescript.github.io/docs/en/common-data-types#shared https://bucklescript.github.io/docs/en/common-data-types#sha... for a type mapping table.
• Vinnl 7y ago
  `a` and `b` would explicitly be cast to any, which is forbidding in strict mode, which is TypeScript's default and recommended mode.
  • virtualwhys 7y ago
    Which is exactly the author's point, in TS you must specify the types (to guarantee type safety), whereas in MLs parameters can be inferred.
• masklinn 7y ago
  > It's simply incorrect.. Is perfectly fine for typescript too. The typescript version will be "inferred" as any, and it will refuse to compile if you set `noImplicitAny`. > So I stopped reading there. Because you could not handle the truth?
• coldtea 7y ago
  >So I stopped reading there. At no point in time anything insightful preceded or followed those words...