Buckle script can be used to link to Elm without writing any JavaScript to
speak of. Say in Elm one wants to call some JavaScript routine with an
integer via a port `callOut` and will receive an integer response via
another port `callIn` as a subscription, then the following code in
BuckleScript will do the hook-up:
let app = [%bs.raw "Elm.Main.fullscreen()"] (* get_app() *)
external rcv_callOut : (int -> unit) -> unit = "" [@@bs.val
"app.ports.callOut.subscribe"]
external snd_callIn : int -> unit = "" [@@bs.val "app.ports.callIn.send"]
let () =
rcv_callOut (fun x -> snd_callIn (x + 1));
etc. ...
with the following JavaScript produced:
app.ports.callOut.subscribe(function (x) {
app.ports.callIn.send(x + 1 | 0);
return /* () */0;
});
Obviously, there is a lot of overhead happening in the background through
the port interface so one wouldn't do this for such a trivial task as an
increment of the integer, but this just shows the interface. Typical use
would be some kind of long running routine that needs to be faster than
what current Elm can produce, and may include progress reports and checks
for cancellation. Normally in JavaScript, there would be no return on the
inner function, but in OCaml every function has a return value even it is a
unit return, for which it returns zero as here; I don't know any way to
prevent this from happening but it doesn't cause a problem as JavaScript
will just ignore it the returned value.
On Monday, 2 January 2017 11:04:10 UTC+7, GordonBGood wrote:
>
> On Sunday, 1 January 2017 22:27:40 UTC+7, Bob Zhang wrote:
>>
>> Note that a high quality optimizing compiler like BuckleScript
>> outperforms native JS significantly > Elm.
>> (See the benchmark here:
>> http://bloomberg.github.io/bucklescript/slides/preview/bb-reveal-example-presentation.html#/5/1
>> )
>>
>>
>> The only reason that I suggest these things is that I agree with Evan
>>> that JavaScript would ideally only be used as necessary in libraries, with
>>> the majority of applications never having to deal with it; however, with
>>> the current version there seems to be various applications where Elm code
>>> is not performant enough.
>>>
>>
> Bob/Hongbo, I don't argue with you (and you have clearly demonstrated)
> that BuckleScript (and the OCaml front end) are fast. The reasons I don't
> care for OCaml particularly for general use is the paucity of primitive
> data types (as discussed) and limitations of its type system in general as
> compared to more modern ML type languages such as F# (which syntax and use
> I quite like) and Haskell, and the feeling I get using the OCaml syntax
> that it is a prototype of a modern language but not quite there. With
> clearly long familiarity, you are used to overcoming OCaml's "warts", but
> for others these are real obstructions to the common acceptance of the
> language.
>
> You have replied that for BuckleScript's use with JavaScript as output
> also having limited types, the limitations of primitive types has been
> overcome, and I can see how it could as long as one is using a 64-bit OCaml
> compiler so that Int's are large enough to fully express a 32-bit range
> (remember those OCaml tag bits). For this limited use of output to
> Javascript, many of Ocaml's "warts" aren't a problem.
>
> My latter complaint is more apt I believe:
>
> 1. Come now, tag bits like a dynamically typed Lisp-type language for
> a statically typed language? This really harks back to List-type
> dynamicall typed languages.
> 2. Requirement for semicolons as an end of block (or even dual
> semicolons such as global imports?) at certain key places, although
> granted
> those are mostly for imperative forms of code with `do` thatwe would
> prefer not to use (while/for)?
> 3. In spite of being white space delimited, also requiring that sub
> blocks be delimited by begin..end or brackets?
> 4. I'm sure there are others as in the definition of the type system...
>
> However, your implementation is most usable and valuable as for this use
> you seem to have overcome most of the limitations of OCaml, and for many
> small uses your provision of a the online compiler in the "try in browser"
> page is so useful that one doesn't have to go to the work of downloading a
> good IDE (OCaml-Top or Visual Studio Code plus plugin) plus the node
> bucketscript plugin. Thank you very much for bringing it up, as it appears
> that your implementation is ahead of the alternate JavaScript Transpilers
> as to stability and immediate usability, perhaps partially due to the
> stability of OCaml. It is impresive that a fairly young project produces
> such incredibly efficient JavaScript code! It seems that your project is
> also well supported by a corporation, so it isn't going to disappear as so
> many other one-horse-pony's do over the course of time.
>
> As developer of the program, you can be most proud. Your project is both
> practical and eminently usable.
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
