On Tue, Dec 9, 2014 at 5:41 AM, Sean Seefried
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.
It still wouldn't be trivial since all kinds of platform assumptions are still baked into the code, for example the word size, sizes/alignment of foreign data types, endianness and all error constants in the base library. If you compile a program with the wrong constants you get very weird error messages and problems (I've had this problem). Bytecode also doesn't support certain constructs, like unboxed tuples, so it'd need to be extended if we wanted to run a whole program from bytecode. To do it properly would involve configuring packages for two different platforms, which would either mean supporting multiple versions/targets in a single GHC and package db, or a massive overhaul of how platform specifics are handled in libraries. Either way it'd be a lot more work than compiling Template Haskell code for the target and shipping it there to run it [1]. Eventually I'd still like to see multiple targets properly supported, for example for heterogeneous cloud haskell environments, but given the changes required in the Cabal and GHC, this looks like a strictly longer term option. luite [1] https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html