Using the GHC API to write an interpreter

[Simon Marlow]

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,
> 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#021fe2a9

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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160627/6c7b1e2f/attachment.html>