On 2016-11-25 12:11, Simon Marlow wrote:
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