About cabal and compatibility

[Isaac Jones]

Robert Dockins <robdockins at fastmail.fm> writes:

> [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