Using the GHC API to write an interpreter

[Christopher Done]

Thanks! It's strange to think there was once no GHCi. This is an
interesting piece of Haskell implementation history! =)

On 27 June 2016 at 15:27, Simon Marlow <marlowsd at gmail.com> wrote:

>
>
> 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/20160628/4f4e9faf/attachment-0001.html>