'cabal ghci' mode

[guest]

See  http://www.haskell.org/pipermail/haskell-cafe/2008-October/049830.html and  http://www.haskell.org/pipermail/haskell-cafe/2008-October/049913.html. Two things would be nice: "cabal ghci" loads the main-is file in ghci; and "cabal ghci Data.My.Module" loads the listed modules in ghci.

Reiner

[duncan]

Obviously it should also pre-process any necessary modules, compile C files and call ghci with all the right flags.

[SamB]

Replying to duncan:

Obviously it should also pre-process any necessary modules, compile C files and call ghci with all the right flags.

Would this still load any previously-built (and not stale) .o files?

[duncan]

Replying to SamB:

Would this still load any previously-built (and not stale) .o files?

I don't see why not. That's up to ghc's normal recompilation checker.

[SamB]

How would one go about attempting to implement this?

[tibbe]

I've really missed this feature while developing network-bytestring where all files are either .hsc or .cpphs.

[batterseapower]

I'm about to attach a patch I slapped together that implements this functionality. However, I just talked to Duncan and he says:

dcoutts: BSP_: btw, if possible it'd be nice to export appropriate util functions from the GHC module and actually implement the feature in the cabal program (cabal-install package)
[23:36] dcoutts: BSP_: eg we should be able to reuse a function for constructing ghc command lines
[23:36] BSP_: it wasn't clear to me what the division of responsibility between cabal and cabal-install was
[23:36] dcoutts: BSP_: here's how I see it now...
[23:36] dcoutts: the program is for the user interface, it's a tool for devs
[23:37] rfh_ left the chat room.
[23:37] dcoutts: the lib is there to provide an implementation of the Cabal build system interface, which is currently specified as a command line interface
[23:37] thetallguy1 left the chat room. (Read error: 104 (Connection reset by peer))
[23:38] BSP_: ok.. but the line is definitely blurred by the presence of stuff like CommandUI in the Cabal library itself 
[23:38] cognominal left the chat room. (Read error: 113 (No route to host))
[23:38] dcoutts: the lib has to implement a minimal cli so that package build scripts can call configure, build etc
[23:39] dcoutts: BSP_: the crucial test I think is, does the rpm build script need it
[23:40] dcoutts: I mean consider a random source rpm that has scripts for doing the build
[23:40] BSP_: OK
[23:40] dcoutts: it needs to configure, build, haddock, install
[23:40] dcoutts: it's a machine api
[23:40] dcoutts: where as cabal ghci blah is definitely aimed at end users, humans
[23:41] BSP_: right
[23:41] BSP_: btw i've called it "cabal interactive" instead, since theoretically you could implement the same thing for other compilers..
[23:42] dcoutts: BSP_: good, I do have qualms about it being too ghc specific
[23:42] dcoutts: BSP_: and if people complain about the length of the command then we can remind them that we do provide command line completion!
[23:42] BSP_:
[23:43] dcoutts: currently only for bash, but others would be easy, the feature is built into cabal itself
[23:44] thetallguy1 joined the chat room.
[23:53] dcoutts: BSP_: if you're working on that area perhaps I can persuade you to do a little refactoring of the GHC module, particularly the way ghc command lines are constructed
[23:54] BSP_: dcoutts: there is a lot of redundancy - but perhaps I should wait for your patches before changing it any further
[23:54] dcoutts: Saizan and I started on an approach with a big GhcOptions record and a function renderGhcOptions :: GhcOptions -> [String]
[23:55] dcoutts: the idea is that functions that generate or mess with options would use the nice structured GhcOptions values
[23:55] dcoutts: I've got half an implementation of the idea I can send you
[23:57] dcoutts: BSP_: pushing the changes now...
[23:57] BSP_: dcoutts: cheers
[00:00] dcoutts: BSP_: some early attempts here http://haskell.org/~duncan/cabal/GHC.hs
[00:00] dcoutts: diff it vs the current ./Distribution/Simple/GHC.hs
[00:00] pumpkin: oh wow, it's BSP on IRC!
[00:01] dcoutts: BSP_: it's the commented out bit about GhcOptions
[00:01] dcoutts: BSP_: so we'd make GhcOptions an instance of Monoid and functions like packageHsGhcOptions :: BuildInfo -> LocalBuildInfo -> GhcOptions
[00:01] BSP_: pumpkin: hey there  i think i recognise your name from github..
[00:02] pumpkin: yup! 'tis me
[00:02] BSP_: dcoutts: right, i'll take a look - no promises though 
[00:02] dcoutts: BSP_: sure 
[00:02] dcoutts: BSP_: ideally it'd make it easy for you to do the ghci bits in an external module, in cabal-install
[00:03] dcoutts: BSP_: ah, of course we'll have to branch cabal-install and have the new head branch use the head version of the Cabal library
[00:04] dcoutts: the current stable cabal-install uses the released stable Cabal version
[00:06] BSP_: ok

So in summary:

• The GHC module needs a serious refactoring, perhaps using a GhcOptions? monoid
• The patch should be for cabal-install, not cabal
• The second thing kind of depends on the first, so it makes sense to do these together

I'll make these changes to the patch if I find the time, but if not at least the incomplete patch is here with the ticket.

[batterseapower]

Implementation of 'cabal interactive' in the Cabal library

[duncan]

initial work on a GhcOptions? type and renderGhcOptions :: GhcOptions? -> [String]

[duncan]

Half the patches now merged.