Simon, As Sumit said, we use dynCompileExpr for core functionality of IHaskell. I am not really sure how the change you are proposing affects that, though.
We use dynCompileExpr in several places for evaluation inside the interpreter context: 1. Evaluating a Haskell expression in the interpreter context, converting the result to a ByteString, then using fromDynamic to extract the bytestring and convert it to a value in the compiled context. 2. Getting a file handle from the interpreter context to the compiled context; this does not actually use dynCompileExpr because there were some bugs with dynCompileExpr and so I had to literally copy source from InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the issue was that dyncompileexpr imported and then unimported Data.Dynamic, and this messed with data declarations that had already been created in the interpreter context) 3. Extracting IO a values from the interpreted context to the compiled context so that they could be run; this is necessary to get displayed values from the interpreter back to the compiled code. I think two of our uses, which are both very central to the way IHaskell works, would be impacted by requiring a Binary instance (or similar), which is what I think you are proposing (since we have two uses at least where we marshall `IO x` values via dynCompileExpr, which cannot be serialized, I believe.) I am sure that there are alternative ways to do what we are doing, but they are probably not simple and would take quite a bit of work. -- Andrew On Tue, Nov 17, 2015 at 6:29 AM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > How does this interact with typechecker plugins? I assume they would still > happen in GHC's process. > > I've also been thinking about designing and implementing a mechanisms > where programmers could specify custom pretty-printers for their types, and > GHC would use these pretty-printers in error messages. This action would > also probably need to be in the same process. > > Would either of these ideas be affected? My guess is "no", because we > should be able to be selective in what gets farmed out to the second > process and what stays locally. > > Richard > > On Nov 17, 2015, at 5:10 AM, Simon Marlow <marlo...@gmail.com> wrote: > > > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this has > quite a few benefits, and would let us kill some of the really awkward > hacks we have in GHC to work around problems that arise because we're > running interpreted code and the compiler on the same runtime. > > > > I summarised the idea here: > https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. Are > people relying on dynCompileExpr for anything? > > > > Cheers, > > Simon > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
