<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 June 2016 at 13:31, Christopher Done <span dir="ltr"><<a href="mailto:chrisdone@gmail.com" target="_blank">chrisdone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 27 June 2016 at 10:01, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> On 26 June 2016 at 11:28, Christopher Done <<a href="mailto:chrisdone@gmail.com">chrisdone@gmail.com</a>> wrote:<br>
>><br>
>> I've been pondering how feasible it would be to:<br>
>><br>
>> * Compile in stages a module with the byte code linker<br>
>> * Keep hold of the Core source<br>
>> * Interpret the Core AST within Haskell<br>
><br>
> Interestingly, the first implementation of GHCi was a Core interpreter, but<br>
> it ran into a lot of problems.  For starters it would have unsafeCoerce<br>
> everywhere.  Support for unboxed values is very very difficult.<br>
<br>
</span>What year is that implementation from? I wouldn't mind taking a look<br>
for it in the GHC repo history.<br>
<span class=""><br></span></blockquote><div><br></div><div>I think around here is a good place to start looking: <a href="https://phabricator.haskell.org/rGHCbca9dd54c2b39638cb4638aaccf6015a104a1df5#021fe2a9">https://phabricator.haskell.org/rGHCbca9dd54c2b39638cb4638aaccf6015a104a1df5#021fe2a9</a><br><br></div><div>Cheers<br></div><div>Simon<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
>> * is not tagless, so we preserve type info<br>
><br>
> Not sure what you mean here.  Your interpreter would be running on top of<br>
> the same RTS with the same data representation, so it would have to use the<br>
> same tagging and representation conventions as the rest of GHC<br>
<br>
</span>That's true, if a value comes from a compiled RTS function with a<br>
polymorphic type then I don't know what its real type is to marshal it<br>
properly. Drat.<br>
<span class=""><br>
>> * allows top-level names to be redefined<br>
><br>
> This you could do with the extisting byte-code interpreter, by instead of<br>
> linking Names directly you link to some runtime Name-lookup function.  You<br>
> would probably want to revert all CAFs when the code changes too; this is<br>
> currently not implemented for byte code.<br>
<br>
</span>Right, I considered this but without the type information it's going<br>
to blow up if I change the arity of a function or a data type or<br>
whatever.<br>
<span class=""><br>
>> * when a function is applied, it checks the type of its arguments<br>
><br>
> Aha, but what if the arguments come from compiled code?  GHC doesn't carry<br>
> type information around at runtime, except that it is possible reconstruct<br>
> types in a limited kind of way (this is what the GHC debugger does).<br>
<br>
</span>Indeed, from compiled code e.g. id then id (undefined :: Foo) would<br>
come back as something unidentifiable as being of type Foo. That's the<br>
flaw in my plan.<br>
<br>
Looks like the current interpreter would have to be extended to<br>
support this or a whole new one re-implementing all the primitives like<br>
in GHCJS.<br>
<br>
Thanks!<br>
</blockquote></div><br></div></div>