<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    On 2016-11-25 12:11, Simon Marlow wrote:<br>

    <blockquote

cite="mid:CANsrgPLfWm1brzrbPrUTXQs3Gp6TnHZT=rpyJW5as3=u28NrtA@mail.gmail.com"

      type="cite">

      <div dir="ltr">

        <div class="gmail_extra">

          <div class="gmail_quote">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.</div>

        </div>

      </div>

    </blockquote>

    <br>

    Maybe this separation and the preceding discussion of the two

    possible solutions suggests a usable approach to the architecture of

    this future system?<br>

    <br>

    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.<br>

    The cross-compiler approach is more or less just a variation on this

    with far less overhead.<br>

    So why not build an architecture that supports both solutions?<br>

    <br>

    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, <i>a </i><i>kind

      of meta-language to describe compiler deployments</i> – and

    Haskell is great for describing languages.<br>

    <br>

    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?<br>

    <br>

    Cheers,<br>

    MarLinn<br>

  </body>

</html>