<div dir="ltr">On 26 June 2016 at 11:28, Christopher Done <span dir="ltr"><<a href="mailto:chrisdone@gmail.com" target="_blank">chrisdone@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I've been pondering how feasible it would be to:</p>
<p dir="ltr">* 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></p></blockquote><div><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
* When encountering built-in/primitives (or things from other libraries), we compile that Core term and link it as an HValue and then run it with the arguments expected. So () would be such a HValue, as would be "show" which in interpretable unoptimized Core would take an extra argument for the Show instance. When passing in values to such "foreign" functions it would wrap them up in an interpretive way. </p>
<p dir="ltr">This is the hypothetical idea, it seems like it would yield a really trivial way to write a new and interesting interpreter for GHC Haskell without having to re-implement any prim ops, ready to work on regular Haskell code.</p>
<p dir="ltr">In my case, I would use this to write an interpreter which:</p>
<p dir="ltr">* is not tagless, so we preserve type info<br></p></blockquote><div>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</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
* allows top-level names to be redefined<br></p></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
* when a function is applied, it checks the type of its arguments</p></blockquote><div>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).<br><br></div><div>Cheers<br></div><div>Simon<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Both of these are pretty much necessary for being able to do in-place update of a running program while developing (a la Emacs or Smalltalk), and type tags let us throw a regular Haskell exception of type error, a la deferred type errors. It means in your running program, if you make a mistake or forget to update one part, it doesn't bring the whole program down with an RTS error or a segfault, maybe a handler in a thread (like a server or a video game) throws an exception and the developer just updates their code and tries again.</p>
<p dir="ltr">I'd love support for something like this, but I'd rather not have to re-create the world just to add this capability. Because it's really just conceptually regular interpreted GHC Haskell plus type tags and updating, it seems like it should be a small diff.</p>
<p dir="ltr">Any input into this? How far away is GHC's current architecture from supporting such a concept? </p>
<p dir="ltr">Ciao!</p>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div></div>