Comments for @UHC

Comment on A Haskell FFI calling convention for Javascript by Atze Dijkstra

Atze Dijkstra — Mon, 01 Nov 2010 21:04:47 +0000

So, it boils down to putting everything in the IO monad, as all fields of an object (except the readonly ones) can then be modified by another thread, no way around it. Which is somewhat of a pity as it does not improve readability.

Comment on A Haskell FFI calling convention for Javascript by Alexander

Alexander — Sun, 31 Oct 2010 04:32:05 +0000

That’s wrong – Chrome and Opera JS engines are multithreaded, although they lock DOM accesses to ensure compatibility with the legacy JS code.

Comment on A Haskell FFI calling convention for Javascript by Jason Dusek

Jason Dusek — Fri, 29 Oct 2010 22:49:24 +0000

DOM programming would seem to be modelled by STM. JavaScript interpreters in browsers (and many outside them) are single-threaded; so there is never any danger of concurrent update of a structure during the “check” phase right before a transaction to the DOM is committed.

Comment on A Haskell FFI calling convention for Javascript by Sjoerd Visscher

Sjoerd Visscher — Fri, 29 Oct 2010 13:33:46 +0000

Interesting!

On thing: NodeList is a live list, so I’d say that nodeListLength needs to be in IO as well.

Comment on Haskell to Javascript backend by Witold Baryluk

Witold Baryluk — Wed, 20 Oct 2010 09:09:31 +0000

Hi,

I’m an author of (not-yet-published) Erlang compiler to JavaScript. (project have about 3 years now, still not enaugh time to finish it, but it works )

I’m highly interested in your work. Keep going, I’m also interested in performance comparison between UHC and pure JavaScript And examples which will show that this have some better characteristic for web development.

Comment on Haskell to Javascript backend by Matt

Matt — Mon, 18 Oct 2010 21:43:59 +0000

I would imagine that each different execution environment has different primitives. If you are executing on an OS (mac, unix, windows), the primitives are console IO and file IO. If you are executing on a browser the primitives are DOM manipulation.

Comment on Haskell to Javascript backend by Atze Dijkstra

Atze Dijkstra — Mon, 18 Oct 2010 18:52:20 +0000

Thanks, I was not aware of this. Makes me curious how you deal with the parts a Javascript environment has difficulty to support, such as file IO. For now UHC does not include such libraries.

The eval function is only overwritten here for explanatory purposes. In the RTS for UHC’s Javascript backend names are chosen differently, e.g. for ‘eval’ instead ‘_e_’ is used, and generated identifiers are prefixed by ‘$’.

Comment on Haskell to Javascript backend by Joe

Joe — Mon, 18 Oct 2010 15:22:19 +0000

Maybe it’s not so widely known but the GHC Javascript backend has been reborn too: http://github.com/sviperll/ghcjs
And you really shouldn’t override the built in eval function, it’s quite confusing and I think it’s even prohibited in the next version of Javascript.

Comment on Haskell to Javascript backend by golubovsky

golubovsky — Mon, 18 Oct 2010 13:16:58 +0000

Hmm, the idea lives on…

BTW it seems like development of WebIDL spec is back from suspended state (the guy who edits the spec is going to publish a new draft).

See http://lists.w3.org/Archives/Public/public-script-coord/ if interested.

Thanks.

Comment on Haskell to Javascript backend by atzedijkstra

atzedijkstra — Mon, 18 Oct 2010 11:47:13 +0000

I have added the source code to a github repository for this entry. It will also be part of the next UHC release, but names will be less clear to avoid possible name clashes.