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 <marlo...@gmail.com> wrote: > > > On 27 June 2016 at 13:31, Christopher Done <chrisd...@gmail.com> wrote: > >> On 27 June 2016 at 10:01, Simon Marlow <marlo...@gmail.com> wrote: >> > On 26 June 2016 at 11:28, Christopher Done <chrisd...@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! >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
