Re: Using the GHC API to write an interpreter

27 Jun 2016

      On 27 June 2016 at 13:31, Christopher Done  wrote:
...
On 27 June 2016 at 10:01, Simon Marlow  wrote:
...
On 26 June 2016 at 11:28, Christopher Done  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.
I think around here is a good place to start looking:
https://phabricator.haskell.org/rGHCbca9dd54c2b39638cb4638aaccf6015a104a1df5...

Cheers
Simon
...
...
...
* 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!