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