On Thu, 2008-08-28 at 10:27 +0100, Simon Peyton-Jones wrote: > | So Cabal takes the view that the relationship between features and > | dependencies should be declarative. > ... > | The other principle is that the packager, the environment is in control > | over what things the package 'sees'. > ... > | that we can and that the approach is basically sound. The fact that we > | can automatically generate distro packages for hundreds of packages is > | not insignificant. This is just not possible with the autoconf approach. > ... > | Do you think that separating the Simple build system from the > | declarative part of Cabal would help? It'd make it more obvious that the > | build system part really is replaceable which currently is not so > | obvious since they're in the same package. I'm not averse to splitting > | them if it'd help. They're already completely partitioned internally. > > > Duncan, I'm not following every detail here, but it's clear that you > have some clear mental infrastructure in your head that informs and > underpins the way Cabal is. Cabal "takes the view that...", has > "principles", and "is clearly partitioned internally". > > These things are clear to you, but my sense it that they are *not* > clear even to other well-informed people. (I exclude myself from this > group.) It's like the Loch Ness monster: the bits above the waves > make sense only when you get an underwater picture that shows you the > monster underneath that explains why the humps surface in the way they > do. > > This isn't a criticism: one of the hardest thing to do is to > accurately convey this underwater stuff. But I wonder whether there > might be a useful paper hiding here? Something that establishes > terminology, writes down principles, explains the Cabal viewpoint, > contrasts with alternatives, and thereby allows discussion about Cabal > to be better informed.
Yes. Of course there is Isaac's existing Cabal paper from '05 but there are also some more recent ideas. http://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/24num.pdf I think the way forward is after the upcoming GHC+Cabal release to take a step back and think about a design document for Cabal-2.x. It should incorporate the things we think were right from the original Cabal design document, things we've learnt along the way and try as much as possible to incorporate the criticisms that people have been making in recent months. The goal should be a design with a somewhat greater ambition than the original Cabal design which was mostly aimed at relatively simple, single package projects (a goal which has mostly been achieved). This would also be the right place to explain the configuration model properly, so that the people who are familiar with the autoconf model don't think we're just crazy. Not that they have to agree with us, but at least we should explain the tradeoffs and limitations in either direction. That should also help to clarify what is a limitation in the model vs what is a limitation in the current implementation of the model in current Cabal. The most obvious and immediate problem (apart perhaps from handling complex multi-package systems) is in specifying dependencies on Haskell code. I did start a discussion on this topic on the libraries mailing list in April/May. We didn't reach any really firm conclusions but it's clear that specifying just module names or just package versions is only an inexact proxy for what we really mean. Modules can be renamed, modules can move between packages, neither capture names or types of exported/imported entities let alone semantics. Various ideas were floated like precisely specifying or inferring interfaces, in a style somewhat like ML functors. > PS: concerning your last point, about "separating the Simple build > system", that might indeed be good. Indeed, the GHC plan described > here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I > think) precisely using the declarative part but not the build-system > part. I don't think it affects that really. GHC would still come with both parts if it were split into two packages and the exported modules and apis would not be changed by splitting. If splitting allowed one part to be separated out and not need to be a boot lib then it'd be a different matter but I don't think that's the case (which I think Ian confirmed in his reply). Splitting might help nhc98 and external perceptions. A possible downside is that it might make bootstrapping Cabal harder. Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users