Using the GHC API to write an interpreter

[Simon Marlow]

On 26 June 2016 at 11:28, Christopher Done <chrisdone at gmail.com> wrote:

> I've been pondering how feasible it would be to:
>
> * Compile in stages a module with the byte code linker
> * Keep hold of the Core source
> * Interpret the Core AST within Haskell
>

Interestingly, the first implementation of GHCi was a Core interpreter, but
it ran into a lot of problems.  For starters it would have unsafeCoerce
everywhere.  Support for unboxed values is very very difficult.

> * When encountering built-in/primitives (or things from other libraries),
> we compile that Core term and link it as an HValue and then run it with the
> arguments expected. So () would be such a HValue, as would be "show" which
> in interpretable unoptimized Core would take an extra argument for the Show
> instance. When passing in values to such "foreign" functions it would wrap
> them up in an interpretive way.
>
> This is the hypothetical idea, it seems like it would yield a really
> trivial way to write a new and interesting interpreter for GHC Haskell
> without having to re-implement any prim ops, ready to work on regular
> Haskell code.
>
> In my case, I would use this to write an interpreter which:
>
> * is not tagless, so we preserve type info
>
Not sure what you mean here.  Your interpreter would be running on top of
the same RTS with the same data representation, so it would have to use the
same tagging and representation conventions as the rest of GHC

> * allows top-level names to be redefined
>
This you could do with the extisting byte-code interpreter, by instead of
linking Names directly you link to some runtime Name-lookup function.  You
would probably want to revert all CAFs when the code changes too; this is
currently not implemented for byte code.

> * when a function is applied, it checks the type of its arguments
>
Aha, but what if the arguments come from compiled code?  GHC doesn't carry
type information around at runtime, except that it is possible reconstruct
types in a limited kind of way (this is what the GHC debugger does).

Cheers
Simon

> Both of these are pretty much necessary for being able to do in-place
> update of a running program while developing (a la Emacs or Smalltalk), and
> type tags let us throw a regular Haskell exception of type error, a la
> deferred type errors. It means in your running program, if you make a
> mistake or forget to update one part, it doesn't bring the whole program
> down with an RTS error or a segfault, maybe a handler in a thread (like a
> server or a video game) throws an exception and the developer just updates
> their code and tries again.
>
> I'd love support for something like this, but I'd rather not have to
> re-create the world just to add this capability. Because it's really just
> conceptually regular interpreted GHC Haskell plus type tags and updating,
> it seems like it should be a small diff.
>
> Any input into this? How far away is GHC's current architecture from
> supporting such a concept?
>
> Ciao!
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160627/f80cfece/attachment.html>