Using the GHC API to write an interpreter

[Christopher Done]

On 27 June 2016 at 10:01, Simon Marlow <marlowsd at gmail.com> wrote:
> 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.

What year is that implementation from? I wouldn't mind taking a look
for it in the GHC repo history.

>> * 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

That's true, if a value comes from a compiled RTS function with a
polymorphic type then I don't know what its real type is to marshal it
properly. Drat.

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

Right, I considered this but without the type information it's going
to blow up if I change the arity of a function or a data type or
whatever.

>> * 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).

Indeed, from compiled code e.g. id then id (undefined :: Foo) would
come back as something unidentifiable as being of type Foo. That's the
flaw in my plan.

Looks like the current interpreter would have to be extended to
support this or a whole new one re-implementing all the primitives like
in GHCJS.

Thanks!