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