[Haskell-cafe] what's the best environment for haskell work?

[Claus Reinke]

>> For another programs (that compile fine with ghc --make), I didn't
>> bother making the package. But I had to find out the package
>> dependencies by building, checking where it fails, and trying to add a
>> package to the dependency list. Maybe there's a better way, didn't
>> find it.
> 
> We do plan to fix this in the same way we resolve missing imports.  
> I had a look to see if I could do it when a user cabalizes the source, 
> but "ghc --make -v" does not include the packages automatically 
> loaded in its output.  Instead we will need to wait for the error then 
> resolve it when the user presses Ctrl+R.

I looked into this for Vim's haskellmode (would also be nice for
cabal itself), never got the time to implement more than 
':show packages', but perhaps this info helps you along:

- 'ghc -v -e ..' instead of 'ghc -v --make ..' avoids the temporary files
    (assuming the file can be loaded by GHCi).

- GHCi's ':show packages' was intended to provide package info,
    but seems to have bitrotted (you could try the undocumented
    internal ':show linker' and please file a ticket for ':show packages').

- to force loading without running the code, one might have to 
    resort to ugly things like:
     ghc -v -e 'snd(main,1)' -e ':show linker' tst.hs

- at which stage, we might as well use something like

    $ ghc -v -e 'snd(main,1)'  tst.hs 2>&1 | grep Load
    Loading package ghc-prim ... linking ... done.
    Loading package integer-gmp ... linking ... done.
    Loading package base ... *** Parser:
    Loading package ffi-1.0 ... linking ... done.
    Loading package ghc-paths-0.1.0.6 ... linking ... done.
    Loading package array-0.3.0.1 ... linking ... done.
    Loading package containers-0.3.0.0 ... linking ... done.

- for automatic package generation, one would also need
    the language extensions in use (among other things);
    unfortunately, the code for that in GHC stops at the
    first missing extension and is not yet written in a way
    that makes it easy to identify all such cases.

- ideally, one would have ghc --show-languages and
    ghc --show-packages, or ghc --mk-cabal, or implement 
    them via GHC API.

Hth,
Claus

PS. if someone started a haskell-tools list (for cross-tool
    interests in haskellmodes, ides, ghc-api clients, etc., I
    would subscribe, though I can't afford the time to do
    much Haskell hacking at the moment)