ghc vs ghci: why can't ghci do everything ghc can do?
simonmarhaskell at gmail.com
Mon Dec 3 06:55:05 EST 2007
Claus Reinke wrote:
> 3) suggestions:
> a) could we have a :make command in ghci that does a 'ghc
> --make' while reusing the information from the current session?
> b) could we have a --prefer-source option for ghci,
> so that 'ghc --make; ghci --prefer-source' will
> try to load all modules from source, but will fall back to
> the existing object files if necessary
> (instead of failing, as -fforce-recomp does)?
> c) allow selective switching between source and
> object files loaded into ghci (:prefer source M,N,..;
> :prefer object O,P,Q,..).
one important restriction (I'm not sure if you forgot this, but I'll point
it out anyway), is that native-code modules can only depend on other
native-code modules. So "falling back to native-code compilation" might
mean throwing away multiple modules already compiled to bytecode. I don't
like the sound of that - it would be better to put a flag in the module's
OPTIONS pragma to indicate object code is required.
There are other proposals for specifying which modules get loaded as
bytecode btw. One is that the modules you name by filename get loaded as
bytecode, the others get loaded as normal. This seems the lightest
solution to me, you would say
:load M.hs N.hs
> the application i have in mind is trying to use ghci on
> non-trivial projects, such as darcs, or even ghc itself:
> - it isn't possible to load all sources into ghci
> - loading all object files is possible, but prevents
> use of ghci features such as ':m *Module',
> ':browse *Module', breakpoints, tags, ..
> - ghci -fforce-recomp fails because it applies to all modules
> - there is substantial setup to do before one can
> call ghc or ghci, so dropping out of a session and trying to
> figure out dependencies and flags
> for compiling individual modules by hand isn't
(with the above extension)
More information about the Glasgow-haskell-users