I am not sure I entirely understand your proposal, but a good way of finding out if it works is giving it a try.
Excerpts from Christopher Done's message of 2016-06-26 06:28:55 -0400: > 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 > * 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. I don't understand what the bytecode format has to do here. Since your suggestion is to just store Core you can just compile to object code. I prototyped "fat interface" files https://ghc.haskell.org/trac/ghc/ticket/10871 which store core into interface files, so they could be compiled later. The patchset was here: https://github.com/ezyang/ghc/tree/ghc-fat-interface > 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. > > In my case, I would use this to write an interpreter which: > > * is not tagless, so we preserve type info > * allows top-level names to be redefined > * when a function is applied, it checks the type of its arguments > > 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. > > 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. > > Any input into this? How far away is GHC's current architecture from > supporting such a concept? Well, if you are going to support update you need to make sure that the tag information is more elaborate than what GHC currently supports (a type would just be a Name, which is going to get reused when you recompile.) Edward _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs