"S. Alexander Jacobson"
A major problem in every major language I have ever used is module systems that make it all too easy for untracked dependencies to creep silently into code. The result has repeatedly been nasty surprises when moving code between machines. A Haskell example of this problem might look something like this:
* Oh, Network.HTTP is non-standard!? Thats wierd. * Uh Oh. Google reveals at least three different implementations... * Now, how do I determine which one is installed here? * Is there a local copy of the package somewhere? * No? Ok, is it available for download somewhere? * Uhm, is the version I am using still available for download? * Oh, we made local changes too!? What were they? * Ok, we added Network.Socket.SSL. That's standard right? [rinse/repeat] [A lot of detective work later...] * Ok, now we've figured out all the packages, how do we ship them? [shipping strategy devised...] * But what happens if I don't have root/admin on the target machine? [...] * Oh, this package conflicts with something already installed? [etc.]
What does this example have to do with untracked dependencies? Sounds like more of a problem with a lack of a central database ala Hackage.
It is true that Cabal's Build-Depends doesn't do everything you want it to, but your proposal also duplicates some of the functionality of Build-Depends, and makes it so that there are two places where dependencies are stored. We should only have to specify dependencies once.
I agree you should only have to specify dependencies once. But, deferring dependency tracking to the point you are ready to ship (with Cabal or otherwise) is a recipe for disaster.
Actually, it gets checked at build time if you use cabal to build during development. This can fail for (ghc-pkg) exposed packages, though, see the message I just posted.
Strawman proposal 2:
Modify the import syntax to allow package identifiers:
import qualified HaXML HaXML.XML.Parse import HAppS HAppS.ACID import Personal MyLib
Can you relate this proposal to the previous grafting work? It sounds like you're basically just adding a new root to the module hierarchy. My $0.02: I'm still more comfortable with solving this outside the core language, with the package system, cabal, and hackage. (snip)
I don't think it's necessary to specify dependencies with module granularity. This just increases the number of possible error cases, without adding functionality.
If I use multiple packages that export the same module identifier, I need a way to specify which one I want to use. Haskell's existing packaging model doesn't let met do that easily.
Does the grafting proposal solve this problem?
- Package dependencies in Build-Depends could be specified using URLs.
But then dependencies aren't checked at compile time and you can't specify which modules come from which packages.
- Cabal could download, build, and install dependencies without any user intervention.
Download and build? Great! Install? No thank you!
FWIW, right now (thanks to Lemmih), Hackage has a client-server interface so that the client can query hackage as to the dependencies for a given package, and the URLs. So you'll be able to "caball-get foo" and it'll download and install foo's dependencies along with foo. Since it'll be source-packages only (at least at first), there's no "cabal-get build-dependencies-of foo", since to use foo you'll need the build and run-time dependencies. peace, isaac