Hacker News new | past | comments | ask | show | jobs | submit login

I think the ReasonML parser and formatter have numerous issues that'll keep it from being adopted more widely.

Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour.

The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy.

That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead.

An example of lossy translation from Reason -> OCaml:

https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...




You mean using ReasonReact without JSX in OCaml is a pain?

Doesn't it allow to quickly code something like HyperScript-Helpers?


I don't understand, what is being lost here?


`| ((Some (result))[@explicit_arity ]) -> Js.Array.forEach Js.log result`

the explicit_arity being added in. I can't think of other examples at the moment.


As far as I understand, 'lossy' would mean information was lost, right? But here it looks like information has been added.


I agree with that definition.

Maybe lossy is the wrong word, but the transforms historically had gotchas. PPX and what not. Especially when converting between Reason syntax version upgrades and the more stable OCaml syntax (locked to OCaml 4.2 because of bucklescript).

That doesn't necessarily mean lossy, but just that knowing what refmt will error out on depending on the version of Reason the code was written to target vs. locked down ML.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: