status of template haskell + cross compiling plans for 7.8?
stegeman at gmail.com
Thu Jul 4 12:57:15 CEST 2013
On Thu, Jul 4, 2013 at 9:48 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:
> ** **
> Via HWN I read your GHCJS post<http://weblog.luite.com/wordpress/?p=14&date=2013-06-03>this morning. Great work.
> ** **
> It’s silly that you should need to patch GHC. One alternative is to
> absorb your patch<https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/ghc-ghcjs.patch>,
> 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
(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
with their own .hi files)
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
same marshalling as ccall, so if you want to return a Bool, you need to
built-in bool type (and the Haskell True/False constructors are actually
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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs