[Hackage] #382: 'cabal ghci' mode

Peter Gammie peteg42 at gmail.com
Tue Jun 9 00:52:42 EDT 2009


I'm not sure it's appropriate to respond to tickets here, but here  
goes...

I'd like to see the cabal library support invoking an interpreter in  
the same way that it supports invoking a compiler, for the simple  
reason that I want to build a tool on top of it. Specifically, I want  
to use GHCi to do testing, and it really requires Cabal integration to  
work well. I have a prototype that I hope to push out the door  
sometime this month. You can take a look at Lemmih's cabal-test for an  
example of what a Cabal GHCi API would need to provide (at a minimum).

Moreover I think the right generalisation is to think of GHCi/Hugs as  
interpreters (or as having read-eval loops) and GHC/NHC/JHC/... as  
batch compilers, and play to the characteristic strengths of each class.

Thanks also for your feedback on the test hook.

cheers
peter

On 28/05/2009, at 10:06 AM, Hackage wrote:

> #382: 'cabal ghci' mode
> --------------------------------- 
> +------------------------------------------
>  Reporter:  guest               |        Owner:
>      Type:  enhancement         |       Status:  new
>  Priority:  normal              |    Milestone:
> Component:  cabal-install tool  |      Version:
>  Severity:  major               |   Resolution:
>  Keywords:                      |   Difficulty:  normal
> Ghcversion:  6.8.2               |     Platform:
> --------------------------------- 
> +------------------------------------------
> Changes (by batterseapower):
>
> * cc: batterseapower+Cabal382 at hotmail.com (added)
>
> Comment:
>
> 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.
>
> -- 
> Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382#comment:9 
> >
> Hackage <http://haskell.org/cabal/>
> Hackage: Cabal and related  
> projects_______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel

-- 
http://peteg.org/



More information about the cabal-devel mailing list