[snip]
This would greatly simplify the Distribution.Simple.UserHooks structure bringing it from 34 fields to 14 fields, or so.
Downsides: Making pre and post hooks would now be slightly harder, and it would break existing hooks-using code.
I just want to mention that these kind of changes represent represent a VERY big problem. I discussed that issue at some length in an email I intended to send to this list very recently, but it seems to have gotten lost. So, to recap: Suppose Alice writes a project A with a Cabal build system that relies on user hooks? Now the interface changes. Bob writes a Cabal build system using the new user hooks for project B. Alice doesn't have time or inclination to update her build system (it still works right? Besides, Alice wants to work on project A; she doesn't want to rewrite her build system every time the cabal folks have a new good idea). Now Jow (Debian package maintainer/gentoo haskell user/whatever) wants to build both projects A and B. What version of Cabal should Joe have? How does he know how to enable the correct versions for which packages, and what versions of which packages? Ugh! What a nightmare. The interesting thing is that cabal seems to solve the versioning problem for most every library except itself! The solution: I suggest that the cabal team very seriously consider using the Eternal Compatibility in Theory method to manage interface change. http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory Rob Dockins