4 ms·

Any Reason code can be linked to OCaml code, because OCaml = Reason. In fact, they are only syntactically different. That is, Reason is an alternate syntax for

by nv-vn 9y ago

Any Reason code can be linked to OCaml code, because OCaml = Reason. In fact, they are only syntactically different. That is, Reason is an alternate syntax for OCaml. BuckleScript/js_of_ocaml can be used in either language, which is to say that any OCaml code can be compiled to JS libraries assuming there are no dependencies that will fail on JS (no need to convert to Reason code or anything). > Being able to use Ocaml [...] packages is a feature It's not, it's a necessity. OCaml and Reason are the same language; it's not like Erlang vs. Elixir which both run on BEAM.

kbenson 9y ago
Are you saying pure Reason,possibly with some JS interop isn't possible? Because that sounds like not using an Ocaml packages to me, which means they aren't a necessity.
- nv-vn 9y ago
  Pure Reason exists, but you can just use `refmt` to convert any OCaml code to Reason (which isn't even necessary, since they both get compiled to the same thing and are stored in the same syntax tree).
  - kbenson 9y ago
    What I was commenting on was the statement that being able to use Ocaml packages is a necessity, and specifically as a rebuttal to my saying being able to use them is a feature. The implication I get from that is that pure ReasonML to JS without Ocaml packages is not possible, which is why I asked. There of course may be some difference on what people consider an Ocaml package, but I would consider anything ReasonML comes with as available in the core as not an Ocaml package, even if that's what provides the support underneath it all, as it's now part of the ReasonML spec (and if the Ocaml package was deprecated, they would find some other way to provide the same underlying functionality so the API did not change). In any case, that statement about it being a necessity confused me.
    - nv-vn 9y ago
      Sorry, to clarify I mean that by design OCaml = Reason. The only way it would not be possible to link the two would be with artificial restrictions. Though they are very different looking, they share the exact same semantics, type system, module system, compiler pipeline, etc. Past parsing, the two languages become the same. I used necessity to mean that for ReasonML to exist, it must be possible (rather than that all Reason programs must necessarily import native OCaml code).
- lilactown 9y ago
  He's saying Reason = OCaml. OCaml can be compiled to to either a native executable, native bytecode, or JS. His comment may sound like a bit of an non-sequitur, but really the confusion comes from: it's not a delineation between OCaml and Reason, but native packages vs. packages that are designed with JS interop in mind. Some native packages can be compiled to JS (e.g. if they don't rely on C FFI), but many interesting ones cannot. js_of_ocaml's version of this story is much better than bucklescript's, but honestly I haven't explored it that much in either one. So what you're saying - write pure OCaml/Reason code, with some JS interop, without relying on native OCaml/Reason packages - is certainly possible! And is probably the most common way of writing apps using the ReasonML syntax today.
skybrian 9y ago
But that's just syntax. As you say, it doesn't mean an arbitrary library written in OCaml will actually run in the browser due to dependencies. It doesn't matter if you can link the code if it won't actually work. I'm reminded of GWT where there is client-only Java, server-only Java, and portable (shared) Java. It's all Java but you definitely have to keep your desired platform's constraints in mind when looking for a library to reuse.
- didibus 9y ago
  You can try Doppio and JavaPoly. Its a full JVM running on JS, and works with most Java libraries that don't do things which would go against what the JS sandbox is allowed to do.
  - aidenn0 9y ago
    Last time I used Doppio, it was really slow. As in something that took 10s on the jvm took hours on Doppio; has performance improved in the last couple of years?

by nv-vn 9y ago

kbenson 9y ago

Are you saying pure Reason,possibly with some JS interop isn't possible? Because that sounds like not using an Ocaml packages to me, which means they aren't a necessity.

nv-vn 9y ago
Pure Reason exists, but you can just use `refmt` to convert any OCaml code to Reason (which isn't even necessary, since they both get compiled to the same thing and are stored in the same syntax tree).
- kbenson 9y ago
  What I was commenting on was the statement that being able to use Ocaml packages is a necessity, and specifically as a rebuttal to my saying being able to use them is a feature. The implication I get from that is that pure ReasonML to JS without Ocaml packages is not possible, which is why I asked. There of course may be some difference on what people consider an Ocaml package, but I would consider anything ReasonML comes with as available in the core as not an Ocaml package, even if that's what provides the support underneath it all, as it's now part of the ReasonML spec (and if the Ocaml package was deprecated, they would find some other way to provide the same underlying functionality so the API did not change). In any case, that statement about it being a necessity confused me.
  - nv-vn 9y ago
    Sorry, to clarify I mean that by design OCaml = Reason. The only way it would not be possible to link the two would be with artificial restrictions. Though they are very different looking, they share the exact same semantics, type system, module system, compiler pipeline, etc. Past parsing, the two languages become the same. I used necessity to mean that for ReasonML to exist, it must be possible (rather than that all Reason programs must necessarily import native OCaml code).
lilactown 9y ago
He's saying Reason = OCaml. OCaml can be compiled to to either a native executable, native bytecode, or JS. His comment may sound like a bit of an non-sequitur, but really the confusion comes from: it's not a delineation between OCaml and Reason, but native packages vs. packages that are designed with JS interop in mind. Some native packages can be compiled to JS (e.g. if they don't rely on C FFI), but many interesting ones cannot. js_of_ocaml's version of this story is much better than bucklescript's, but honestly I haven't explored it that much in either one. So what you're saying - write pure OCaml/Reason code, with some JS interop, without relying on native OCaml/Reason packages - is certainly possible! And is probably the most common way of writing apps using the ReasonML syntax today.

skybrian 9y ago

But that's just syntax. As you say, it doesn't mean an arbitrary library written in OCaml will actually run in the browser due to dependencies. It doesn't matter if you can link the code if it won't actually work. I'm reminded of GWT where there is client-only Java, server-only Java, and portable (shared) Java. It's all Java but you definitely have to keep your desired platform's constraints in mind when looking for a library to reuse.

didibus 9y ago
You can try Doppio and JavaPoly. Its a full JVM running on JS, and works with most Java libraries that don't do things which would go against what the JS sandbox is allowed to do.
- aidenn0 9y ago
  Last time I used Doppio, it was really slow. As in something that took 10s on the jvm took hours on Doppio; has performance improved in the last couple of years?