Using the GHC API to write an interpreter

[Christopher Done]

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.

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?

Ciao!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160626/2bf29a76/attachment.html>