'cabal ghci' mode

[bos]

(Imported from Trac #382, reported by guest on 2008-10-28)

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

[bos]

(Imported comment by @dcoutts on 2008-10-28)

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

[bos]

(Imported comment by @SamB on 2008-10-29)

Replying to @dcoutts:

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?

[bos]

(Imported comment by @dcoutts on 2009-02-03)

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.

[bos]

(Imported comment by @SamB on 2009-02-03)

How would one go about attempting to implement this?

[bos]

(Imported comment by @tibbe on 2009-02-05)

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

[bos]

(Imported comment by @batterseapower on 2009-02-21)

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.

[bos]

(Imported comment by @batterseapower on 2009-05-28)

Implementation of 'cabal interactive' in the Cabal library

[bos]

(Imported comment by @dcoutts on 2009-05-28)

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

[bos]

(Imported comment by @dcoutts on 2011-01-17)

Half the patches now merged.

[bgamari]

What is the status of this? I guess it didn't make the 0.16 milestone?

[23Skidoo]

@dcoutts

Here's the latest status update from @dcoutts:
http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/9309

[gregorycollins]

Removing the "important" tag here: we want this feature, but I wouldn't say that it's blocking anything.

[dcoutts]

Merged into Cabal 1.18.

[redneb]

I just tried it. I have a project like this:

executable foobar
  main-is:             Main.hs
  other-modules:       Foo, Main

When I do cabal repl Foo it loads module Main with ghci. Is this the expected behavior? I would expect it to load Foo.

[byorgey]

I think loading Main is the expected behavior. Can you elaborate on why you would expect it to load Foo?

[redneb]

On Sat, Aug 31, 2013 at 06:39:32AM -0700, Brent Yorgey wrote:

I think loading Main is the expected behavior. Can you elaborate on
why you would expect it to load Foo?

Well, by expected I meant desired. For instance, suppose that in my
above example I was planning to introduce some new functionality for the
executable foobar and I started implementing that by adding a new
function in the module Foo that is not exported (yet). I would like to
be able to test that function by loading Foo with ghci before moving
on.

So I think being able to load arbitrary modules with ghci would be
tremendously useful.

[23Skidoo]

@redneb

So I think being able to load arbitrary modules with ghci would be tremendously useful.

This is planned, but not yet implemented. If you look at the code, there is support for targets like foo:Bar/Baz.hs

[redneb]

On Sat, Aug 31, 2013 at 12:53:48PM -0700, Mikhail Glushenkov wrote:

This is planned, but not yet implemented. If you look at the
code,
there is support for targets like foo:Bar/Baz.hs

The code comments for UserBuildTarget indicate that is for cabal build. I am not sure that this automatically applies for cabal repl
as well. In any case, if this is planned (and I think it should be),
then this issue must remain open.