Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

I agree that Haskell's design gives us a good leg up on the problem of acquiring and comparing APIs. However, I don't think that this manifest solution really buys us enough to justify the complexity. There're also some specific, perhaps resolvable, but unsightly problems, which I outline here: http://www.reddit.com/r/haskell/comments/ydtl9/beyond_package_version_polici... (also another pitch for my proposed solution to this variety of problems) -mgsloan On Fri, Aug 17, 2012 at 2:34 PM, Brandon Allbery wrote:

On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan wrote:

...

Any vastly more complicated and detailed versioning scheme has a huge burden to prove that it won't collapse dramatically more quickly. (Frankly, I think that anything involving "specify every detail of your known dependencies" is dead on arrival from a practical standpoint: it's way too much work.)

If you do it in terms of hashed signatures, you can make the compiler and toolchain do the work for you. The problem with version numbers is that it *is* manual. It can't catch behavioral changes, though; you probably need some kind of epoch override for that in the case where it doesn't come with corresponding API changes.

The reason it's never done is that you can't really do it with C or C++. We can mostly avoid that (the FFI is an issue, but it is anyway: cabal can't really check C stuff, unless you use pkg-config which was two operating modes: exact versions or no versioning).

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe