|
|
|
|
|
|
by sjrd
3481 days ago
|
|
|
> and dead simple FFI That's very accurate. So dead simple that as soon as you want to manipulate something else than primitive values and functions from JS, you hit a dead end. How do you read a field from a JS object? How do you call a JS method? For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with. It's also striking to me that the documentation of PureScript FFI [1] has to teach you what the output of the compiler will be so that you can use the FFI. Am I really supposed to know about those `$`s? What if the compiler improves and changes its internals? I'm sorry if my comment is perceived as a rant, but I can never understand how people can call PureScript's FFI good. Compare it to interoperability in TypeScript, ClojureScript, or Scala.js, and it is way behind! [1] http://www.purescript.org/learn/ffi/ |
|
|
Here's my unfinished, but working code, interfacing Google Apps Script to Purescript https://github.com/kika/purescript-google-appsscript/tree/ma...
Please tell me what is so _dead_ in it.
Though I'm pretty new to Purescript and to the Haskell world in general, it took me almost no effort to write this code once I figured out how Data.Function (renamed Data.Function.Uncurried in the latest Purescripts) works. Probably your issue with Purescript FFI was about not being aware of these helpers (which don't do much help per se, but remove ugly clutter of nested functions in JS code).