One of the main reasons we didn't do this with UHC was that we had to focus on more elementary parts of the FFI/RTS first: dynamic/wrapper imports, object interaction, etc. I must admit that I forgot the exact reasons for not converting between the types automatically, after we had finished with the first bit, though..
On 13 Nov 2012, at 19:18, Christopher Done <[email protected]> wrote: > On 13 November 2012 16:33, J. Stutterheim <[email protected]> wrote: >> Yes, I did check out other work that's been done in this area, albeit only >> briefly. Unless I've overlooked it (which is very much possible), none of >> the other solutions (except Fay) support an FFI that bridges the gap between >> JS's OO and the functional world, like our JS-like language in the foreign >> imports. In real-life situations, where you want to get rid of writing JS >> entirely, but still might want to use existing JS libraries such as jQuery, >> this feature is essential. > > Just a small point, but Fay's FFI differs from UHC/GHC's in that it > natively supports String/Double and functions without needing wrappers > and conversions from CString or whatnot. E.g. you write > > addClassWith :: (Double -> String -> Fay String) -> JQuery -> Fay JQuery > addClassWith = ffi "%2.addClass(%1)" > > and you're already ready to use it. If I recall in UHC last I tried, I > had to do some serializing/unserializing for the string types, and > make a wrapper function for the callback. Whether it makes any sense > for a UHC/GHC-backend to behave like this, I don't know. But people > really like it. _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
