5 ms·

Can you explain what the problem with that syntax is, is there something you couldn't express in ReasonML? It is meant to bridge the gap for existing js develop

Can you explain what the problem with that syntax is, is there something you couldn't express in ReasonML? It is meant to bridge the gap for existing js developers, if I understand it correctly. Regarding the ecosystem, I think the main goal is compilation towards js and js interop, so other backends don't really matter that much, from my understanding. Maybe Ocaml just fit the bill best as a base language equivalent, regarding the features they wanted to map to and from js.

hajile 9y ago
I love JS (which ReasonML tries to emulate), but the traditional ML syntax (elm, haskell, SML, etc) is simply better for me. The extra parens and curly braces everywhere don't really add anything useful to the language while complicating the syntax (well, they help solve some edge cases in Ocaml, but those cases also don't exist in most other MLs). Another result of using Ocaml is that operators aren't overloaded (not bad if you have only a couple types, but quite problematic as the number of primitive types grows). A personal annoyance is the use of JS promises (non-monadic with auto-flatmap). Most of this applies to reason as well. http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/ (I'd note that the goal of Successor ML is to add the most useful Ocaml features into SML). As to why they chose Ocaml. More libraries makes it easier to write tooling. Ocaml has builtin tools to make writing the language much easier. Most importantly, other Facebook teams were already doing a ton of stuff in Ocaml. There are probably a bunch of other reasons, but the ReasonML guys know way more about that than I do.
- elcapitan 9y ago
  Ok, yeah, I guess that's personal preference then. I have only superficial experience with traditional MLs and am currently experimenting with ReasonML, and it just feels more intuitive and productive right from the start, and context switching is easier. With regard to operator overloading, that's the number one issue I had anytime I looked for example at haskell, it's just incredibly hard to figure out what some <=$=> operator or whatever means, and also very hard to google, so for newcomers it's really bad language UI.
  - hajile 9y ago
    Operator overloading has pros and cons. In truth, I'm inclined to agree with you that operator overload should be limited in userland, but I'm a bit incredulous at the choice with primitive data types. There are 12 or so common primitive numeric types baked into hardware. If Ocaml ever expanded to include these all, the effect without overloading would be horrendous.
    - elcapitan 9y ago
      Ok yes, agreed, the separate operators for different numeric types are not exactly very user-friendly either. In the de-facto use case of Reason they shouldn't be such a big deal though (building webapps).
- ernst_klim 9y ago
  >Ocaml is that operators aren't overloaded Which is good since SML ad-hoc polymorphism is broken. Right way to do an ad-hoc is to use classes, type classes or modular implicits.
  - hajile 9y ago
    SML overloading of builtins isn't specifically broken -- it just makes implicit assumptions about data types. That said, I'm with you about typeclasses and Ocaml's modular implicits. If full-blown operator overloading is going to be allowed, modular implicits are definitely the way to go. If only builtin operators can be overloaded (probably a better solution in maintainable software), then a few specific typeclasses (like the current equality one) could be a more pragmatic solution. In this particular case, I'd hedge my bets and use modular implicits, but limit them to a small list of builtin operators.

hajile 9y ago

I love JS (which ReasonML tries to emulate), but the traditional ML syntax (elm, haskell, SML, etc) is simply better for me. The extra parens and curly braces everywhere don't really add anything useful to the language while complicating the syntax (well, they help solve some edge cases in Ocaml, but those cases also don't exist in most other MLs). Another result of using Ocaml is that operators aren't overloaded (not bad if you have only a couple types, but quite problematic as the number of primitive types grows). A personal annoyance is the use of JS promises (non-monadic with auto-flatmap). Most of this applies to reason as well. http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/ (I'd note that the goal of Successor ML is to add the most useful Ocaml features into SML). As to why they chose Ocaml. More libraries makes it easier to write tooling. Ocaml has builtin tools to make writing the language much easier. Most importantly, other Facebook teams were already doing a ton of stuff in Ocaml. There are probably a bunch of other reasons, but the ReasonML guys know way more about that than I do.

elcapitan 9y ago
Ok, yeah, I guess that's personal preference then. I have only superficial experience with traditional MLs and am currently experimenting with ReasonML, and it just feels more intuitive and productive right from the start, and context switching is easier. With regard to operator overloading, that's the number one issue I had anytime I looked for example at haskell, it's just incredibly hard to figure out what some <=$=> operator or whatever means, and also very hard to google, so for newcomers it's really bad language UI.
- hajile 9y ago
  Operator overloading has pros and cons. In truth, I'm inclined to agree with you that operator overload should be limited in userland, but I'm a bit incredulous at the choice with primitive data types. There are 12 or so common primitive numeric types baked into hardware. If Ocaml ever expanded to include these all, the effect without overloading would be horrendous.
  - elcapitan 9y ago
    Ok yes, agreed, the separate operators for different numeric types are not exactly very user-friendly either. In the de-facto use case of Reason they shouldn't be such a big deal though (building webapps).
ernst_klim 9y ago
>Ocaml is that operators aren't overloaded Which is good since SML ad-hoc polymorphism is broken. Right way to do an ad-hoc is to use classes, type classes or modular implicits.
- hajile 9y ago
  SML overloading of builtins isn't specifically broken -- it just makes implicit assumptions about data types. That said, I'm with you about typeclasses and Ocaml's modular implicits. If full-blown operator overloading is going to be allowed, modular implicits are definitely the way to go. If only builtin operators can be overloaded (probably a better solution in maintainable software), then a few specific typeclasses (like the current equality one) could be a more pragmatic solution. In this particular case, I'd hedge my bets and use modular implicits, but limit them to a small list of builtin operators.