Hacker News Reader

Comment by jbverschoor | Hacker News Reader

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?

  let sum = (a,b) => a + b;

Is perfectly fine for typescript too. As for:

  let formatName = product => "Name: "+product.name;

So I stopped reading there.

View on HN

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.

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;

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?

ReasonML ints and floats both compile to JavaScript numbers. See https://bucklescript.github.io/docs/en/common-data-types#sha... for a type mapping table.

> 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?

`a` and `b` would explicitly be cast to any, which is forbidding in strict mode, which is TypeScript's default and recommended mode.

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.

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

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.

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.

> 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) and it is available to reason, but it's syntactically funky (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.

I didn’t mean it as a straw man. I’m not familiar with ReasonML at all and meant to illustrate the example.

>So I stopped reading there.

At no point in time anything insightful preceded or followed those words...

Reply on news.ycombinator.com