RE: finding the dependecies of cabal packages

On 29 July 2005 23:19, Isaac Jones wrote:

Brian Smith writes:

...

I think what VHS.NET does--and what I am/was planning to do--is use Cabal files as projects, but reimplement Distribution.Simple.Build et. al. to work in an better in an "interactive" GUI environment than the current system, which is batch-compile oriented. In particular, VHS.NET and maybe my tool will use the GHC API extensively.

For example, using the GHC API I can do dependency analysis that will allow me to say "build just this one source file because that other source file changed." But, Cabal always restarts dependency analysis over at the root modules, which make it too slow for interactive use.

(snip)

Why not work to speed up Cabal's execution time rather than reimplement so much from scratch, and in a compiler-dependent way?

There's nothing inherent about Cabal's interface that makes it do things in a batch, or slows compilation time. It uses GHC's --make flag (though it always relinks the library, which is not always necessary).

If your tool is written in Haskell, and could be made compiler agnostic, perhaps we could add such features to cabal itself... maybe we could have a "./setup build --continuous" which emits status to a file or uses a socket interface or something in order to communicate w/ eclipse, VS, and your tool, since they often want the same kind of information.

Brian is talking about having access to the same facilities that Visual Haskell uses when editing a Cabal project in the environment. For example, when a source file is edited (without even being saved), we can invoke the GHC API to re-typecheck it in the context of the rest of the project, and ask GHC about the types of its identifiers. This is an interactive application, and it needs a programmatic interface so that state can be maintained between calls. A command-line interface isn't the right thing here. I suppose the question is whether there is a useful re-usable abstraction that we can provide as part of the Cabal libraries. Essentially, it would be an abstraction over the GHC API that communicates the details of the program in terms of a PackageDescription. Actually, this would make more sense as part of the GHC API rather than part of Cabal (you don't want a dependency from Cabal on the ghc package, but ghc already depends on Cabal). Using this abstraction, we could construct "ghci --cabal" very easily. Using it in Visual Haskell would be tricky, because I believe we have a different internal representation of PackageDescription. Brian - if you'd like to think about the API, I'll be happy to comment on it. Cheers, Simon