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_policies/c5uro04 (also another pitch for my proposed solution to this variety of problems) -mgsloan On Fri, Aug 17, 2012 at 2:34 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan <b...@serpentine.com> > 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 allber...@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 > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
