ghc vs ghci: why can't ghci do everything ghc can do?
Claus Reinke
claus.reinke at talk21.com
Wed Nov 28 09:37:46 EST 2007
1) is there a single place/wiki/ticket that collects all the
deficiencies of ghci, compared to ghc? things like:
a) which platforms have ghc, but not ghci
b) which features are available in ghc, but not in ghci
c) does ghci encounter bugs where ghc would succeed
d) which of these deficiencies are temporary, which
are likely to stay
2) given that ghci is ghc --interactive, why are there
any cases of b/c above at all?
wouldn't it be possible for ghci to try its stuff, but
to fall back to ghc only for those modules which
it can't handle from source itself (yet)?
- we can do ghc --make; ghci, to get around issues
- we can do ghci -fforce-recomp, to get to sources
but those two are rather coarse-grained, and require
too much manual tweaking to get the effect of creating
a ghci session with as many modules from source as
possible, and all others from object files.
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,..).
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
practical
- there is often a configurable makefile, so that
one can use the same setup for calling either
'ghc --make' or 'ghc --interactive'; but, within
the latter, one cannot simply switch to full
:make or to selective --prefer-source, without
losing the setup
ideally, ghci would simply work whereever ghc
works, and would provide its additional features
for as many modules as it can. but in the interim,
having 3a and especially 3b would help me a lot.
3c would also be nice, too, but not as urgent as 3b.
i find it sad that, currently, there is this gap that
doesn't allow me to make full use of ghci's features
for larger projects such as darcs or ghc.
is hoping for 3b realistic?
claus
More information about the Glasgow-haskell-users
mailing list