<div dir="ltr">Thanks Luite,<div><br></div><div>You've obviously looked into this a lot more deeply than I have. In a perfect world though,</div><div>wouldn't it be good for the bytecode to be platform independent? Theoretically we know this to be</div><div>possible because the JVM has been around for a long time now. If the bytecode could be made</div><div>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? </div><div><br></div><div>Sean</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 December 2014 at 21:03, Luite Stegeman <span dir="ltr"><<a href="mailto:stegeman@gmail.com" target="_blank">stegeman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 9, 2014 at 5:41 AM, Sean Seefried <<a href="mailto:sean.seefried@gmail.com">sean.seefried@gmail.com</a>> wrote:<br>
><br>
><br>
> 1. This could solve the Template Haskell on cross compiler's dilemma. Currently, the problem is that a cross compiler will produce object code for the target machine which cannot be run on the host machine. But if this were bytecode the problem would be trivial to solve.<br>
><br>
<br>
</span>It still wouldn't be trivial since all kinds of platform assumptions<br>
are still baked into the code, for example the word size,<br>
sizes/alignment of foreign data types, endianness and all error<br>
constants in the base library. If you compile a program with the wrong<br>
constants you get very weird error messages and problems (I've had<br>
this problem). Bytecode also doesn't support certain constructs, like<br>
unboxed tuples, so it'd need to be extended if we wanted to run a<br>
whole program from bytecode.<br>
<br>
To do it properly would involve configuring packages for two different<br>
platforms, which would either mean supporting multiple<br>
versions/targets in a single GHC and package db, or a massive overhaul<br>
of how platform specifics are handled in libraries. Either way it'd be<br>
a lot more work than compiling Template Haskell code for the target<br>
and shipping it there to run it [1]. Eventually I'd still like to see<br>
multiple targets properly supported, for example for heterogeneous<br>
cloud haskell environments, but given the changes required in the<br>
Cabal and GHC, this looks like a strictly longer term option.<br>
<br>
luite<br>
<br>
[1] <a href="https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html" target="_blank">https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html</a><br>
</blockquote></div><br></div>