You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7033 Reporter:@bobzhang Assigned to:@alainfrisch Status: resolved (set by @alainfrisch on 2016-12-06T18:42:57Z) Resolution: fixed Priority: normal Severity: feature Fixed in version: 4.04.0 Category: standard library
Bug description
solution 1(currently what I did):
add is_js to sys.mlp and a primitive "caml_is_js", for the c primitive, it always return false then the javascript backend will change its semantics
solution 2 (a more general solution)
add two primitives Ptrue and Pfalse
so the user can write
external is_js : unit -> bool = "%false" [@@js.call "%js"]
The motivation is that user can choose different code for different environment, native, client environment, and nodejs environment, a simple optimization in the compiler would help eliminate the cost
Thanks, Hongbo
The text was updated successfully, but these errors were encountered:
Note that if we can lift the restriction that primitives can be nullary when annotated with attributes "js"
it can be simplified a bit as follows:
external is_js : bool = "%false" [@@js.call "%js"]
Is this really a desirable feature, though? One of the nice things about js_of_ocaml is that you don't need to adjust your programming style just because you're targeting a different backend.
I dont expect this flag to be used everywhere, but it's occasionally useful and will help boost js backend performance significantly.
There are two use cases for a js backend:
Running your ocaml program in a closed ecosystem under js platform (which is perfect for js_of_ocaml and it delivers reasonable performance)
Make js as the major backend (integrate your OCaml code closely with browser/nodejs ecosystem for lots of benefit). Currently my js backend(still work in progress) generate code significantly smaller than js_of_ocaml and even faster code, in this scenario, I would say it is worth to tweak the OCaml a bit to make the js a better target platform. In theory (and in practice), the OCaml generated javascript code should be running faster than hand written JS code.
I would say that the Javascript ecosystem alone is very attractive, for example, now I can debug my ocaml programs using webstorm IDE (the javascript debugger),.
I'm in favor of exposing a primitive to query the execution backend, which could be bytecode/native/js_of_ocaml/Hongbo's new js backend/... Something similar to Sys.os_type.
Original bug ID: 7033
Reporter: @bobzhang
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2016-12-06T18:42:57Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 4.04.0
Category: standard library
Bug description
solution 1(currently what I did):
add
is_js
to sys.mlp and a primitive "caml_is_js", for the c primitive, it always return false then the javascript backend will change its semanticssolution 2 (a more general solution)
add two primitives Ptrue and Pfalse
so the user can write
external is_js : unit -> bool = "%false" [@@js.call "%js"]
The motivation is that user can choose different code for different environment, native, client environment, and nodejs environment, a simple optimization in the compiler would help eliminate the cost
Thanks, Hongbo
The text was updated successfully, but these errors were encountered: