status of template haskell + cross compiling plans for 7.8?

[Luite Stegeman]

On Thu, Jul 4, 2013 at 9:48 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

>  Luite****
>
> ** **
>
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130704/887b3d10/attachment.htm>