Making (useful subsets of) bytecode portable between targets

MarLinn monkleyon at googlemail.com
Fri Nov 25 18:04:13 UTC 2016


On 2016-11-25 12:11, Simon Marlow wrote:
> We basically have two worlds: first, the compile-time world. In this 
> world, we need all the packages and modules of the current package 
> built for the host platform. Secondly, we need the runtime world, with 
> all the packages and modules of the current package cross-compiled for 
> the target platform.

Maybe this separation and the preceding discussion of the two possible 
solutions suggests a usable approach to the architecture of this future 
system?

First, let me reframe the "runner" idea. In a real-world environment, 
this seems like a viable solution either with two separate machines or 
with a VM nested in the main build machine. In both cases, we would need 
two parts of the compiler, communicating over customized channels.
The cross-compiler approach is more or less just a variation on this 
with far less overhead.
So why not build an architecture that supports both solutions?

I practice, this would mean we need a tightly defined, but flexible API 
between at least two "architecture plugins" and one controller that 
could run on either side. To me, this sounds more like a build system 
than a mere compiler. And I'm okay with that, but I don't think 
GHC+Cabal alone can and should shoulder the complexity. There are nice, 
working build-systems out there that could take over the role of the 
controller, so all GHC and Cabal would have to offer are parsing, 
modularized steps, and nice hooks. In other words, /a //kind of 
meta-language to describe compiler deployments/ – and Haskell is great 
for describing languages.

Here's yet another idea I'd like to add, although it is rather silly. 
The idea of a meta-language that describes a conversion structure seems 
very close to what Pandoc is doing for documents. And while Pandoc's 
architecture and history make it a bit static, GHC can still learn from 
it. Maybe, someday, there could even be a bigger, even more over-arching 
build language that describes the program, the documentation, and the 
deployment processes of the whole system?

Cheers,
MarLinn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161125/adaeb188/attachment-0001.html>


More information about the ghc-devs mailing list