Using the GHC API to write an interpreter
marlowsd at gmail.com
Mon Jun 27 13:27:46 UTC 2016
On 27 June 2016 at 13:31, Christopher Done <chrisdone at gmail.com> wrote:
> 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,
> > 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:
> >> * 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
> > 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.
> > 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
> >> * 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
> > type information around at runtime, except that it is possible
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs