[Haskell-cafe] External representation of GHC bytecode

[Sean Seefried]

If what you say is true then I think I have some holes in my understanding
of TH. Aren't AST splices, by definition, just generated Haskell source
code? Isn't the whole idea that TH produces source code as if a programmer
wrote it in the first place? How is this platform dependent?

My understanding of Template Haskell was that something like the following
happened:

1. Code generating functions in a module (call it module M) are compiled to
an object file.
2. A modules, call it P, that wishes generate code imports module M and
runs this code at compile time.

But as far as I can tell this only generates *source code*. P then needs to
be compiled to object code.

The problem in the cross compiler situation is that the dynamic linker
can't load the code in M.o
since that has been compiled for the target machine, not the host.

Apart from that though, I don't see what is platform specific about the
code *generated* in module P by the functions imported from module M. It's
just source code isn't it? Not object code.



Sean

On 9 December 2014 at 22:02, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Tue, Dec 9, 2014 at 5:27 AM, Sean Seefried <sean.seefried at gmail.com>
> wrote:
>
>> If the bytecode could be made
>> to be platform independent -- and I know this would be a *lot* of work --
>> then we'd have a pretty good solution for Template Haskell with cross
>> compilers, wouldn't we?
>>
>
> I think you're missing the point a bit; such a setup would work for
> runghc, but TH needs to be aware of both the host (in this case that'd be a
> platform-independent VM bytecode) and the target (since it is generating
> AST splices for a specific target). The latter is much harder than the
> former.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141209/6ea82587/attachment.html>