Using the GHC API to write an interpreter

[Edward Z. Yang]

I am not sure I entirely understand your proposal, but a good
way of finding out if it works is giving it a try.

Excerpts from Christopher Done's message of 2016-06-26 06:28:55 -0400:
> 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
> * 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.

I don't understand what the bytecode format has to do here. Since
your suggestion is to just store Core you can just compile to object
code.

I prototyped "fat interface" files https://ghc.haskell.org/trac/ghc/ticket/10871
which store core into interface files, so they could be compiled later.
The patchset was here: https://github.com/ezyang/ghc/tree/ghc-fat-interface

> 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
> * allows top-level names to be redefined
> * when a function is applied, it checks the type of its arguments
> 
> 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?

Well, if you are going to support update you need to make sure that the
tag information is more elaborate than what GHC currently supports
(a type would just be a Name, which is going to get reused when you
recompile.)

Edward