On Thu, Jul 4, 2013 at 9:48 AM, Simon Peyton-Jones
Luite****
** **
Via HWN I read your GHCJS posthttp://weblog.luite.com/wordpress/?p=14&date=2013-06-03this morning. Great work. ****
** **
It’s silly that you should need to patch GHC. One alternative is to absorb your patchhttps://github.com/ghcjs/ghcjs.github.com/blob/master/patches/ghc-ghcjs.patc..., or a successor. I think it mostly just extends the FFI and target types with new cases. The patch doesn’t actually include any JS generation, so I’m far from sure how that happens.
GHCJS is a standalone executable, it just uses the GHC API to compile the code to JavaScript (setting the architecture to ArchJavaScript) and native (for Template Haskell). I've intentionally tried to keep the patch minimal with as few GHCJS-specific things as possible, to make it useful for other backends (and also makes it easier for us to change things in GHCJS later). The patch does 4 things: 1. Make the GHC.Prim interface configurable from the GHC API (This makes it possible to change the type of the primops, GHCJS always uses 32 bit types) 2. add a Custom Way, which just adds a tag to the files and filenames (so we can generate native code, used to run TH, alongside JavaScript, each with their own .hi files) 3. Add the JavaScriptFFI extension and "foreign import javascript" 4. Add a ghcjs-prim:GHCJS.Prim.JSRef type as a marshallable FFI type. I haven't submitted the patch here for review yet (except for the first part which was already submitted in February, I've now documented it a bit better) since I'm not happy with the FFI yet. The javascript FFI uses the same marshalling as ccall, so if you want to return a Bool, you need to return a 0 or 1 from the foreign function, even though JavaScript has a built-in bool type (and the Haskell True/False constructors are actually stored as JavaScript's true/false values). I'd like to fix this soon, this or next week. I was thinking of adding some callback to DynFlags that can override the default FFI marshalling behaviour, unless there's a better way. Hopefully with Edsko's upcoming "Source Plugins" patch we can finally use GhcMake functionality. When that's done, I'll be reasonably happy with the way everything works from a GHC API clent. Command line handling, adding extra options in addition to the ones that GHC supports, is still rather messy though.
But it would be even better to make it easier to people to add new backends without modifying GHC, via some kind of plugin interface. ****
Since the patch includes some modification to the parser and a new language extension, I guess it might be hard to fit it in a plugin interface completely. Only point 3 and 4 are specific to JavaScript, and only 4 to GHCJS. Perhaps adding custom architectures is something that could be done better with a plugin. I'd be happy to hear suggestions and update the patch. luite