On Wednesday, January 18, 2017 at 9:53:31 AM UTC-7, Rupert Smith wrote: > > In my view, this also provides very good justification for not allowing > native code into packages.elm-lang.org. Porting Elm to another platform > in this way is manageable. >
Entirely yeah, native code even in core elm is buggy. In my translations I wrote very thin FFI calls to the base-most javascript calls (mostly DOM stuff), fully typed, then built everything on those typed interfaces (it is very typescript'y/purescript'y at that point), but I've had no undefined's, no oddities like that at all, and the old 'native' parts were entirely in OCaml this time, just bound to those very few fully typed FFI calls (which I need to clean them up too, newer versions of bucklescript has simplified making them since I wrote this file). For example, here is the web element node interaction FFI l made (slightly older version as the one at work has a bit more and is a bit more clean), these are the kind of things user code should not write, and indeed an Elm->OCaml compiler should not have such functionality exposed but rather should call to things exposed from OCaml that may use things like this: https://github.com/OvermindDL1/bucklescript-testing/blob/master/src/web_node.ml (and ignore the polyfill at the bottom, I later converted that to pure OCaml/Bucklescript as well) -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
