Robert Dockins
[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.
Are you sure they represent a very big problem in practice and not just in theory? The hooks have been a "very experimental" part of Cabal, as the user manual has always said: You can customize the simple build infrastructure using hooks. [...] See Distribution.Simple for the details, but note that this interface is experimental, and likely to change in future releases. I only know of one or two packages that use the hooks. Do you know of backward compatibility problems that cabal has caused? BTW, I just added a "cabal-version" field to cabal so that if a package requires a particular version of cabal, it can say so. Further, my grand plan is that once stuff gets into hackage, we can try making modifications and seeing if it breaks any packages, and if so, offer patches to those package authors (since it's probably eaiser for cabal hackers to write such patches than most package authors). (snip)
I suggest that the cabal team very seriously consider using the Eternal Compatibility in Theory method to manage interface change.
I'll look at this. peace, isaac