UHC-like JavaScript backend in GHC

[J. Stutterheim]

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 <chrisdone at gmail.com> wrote:

> On 13 November 2012 16:33, J. Stutterheim <j.stutterheim at me.com> 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.