Why upper bound version numbers?
djsamperi at gmail.com
Tue Jun 7 00:19:25 UTC 2016
The odd thing about this is that to upper bound a package that you did
not write (like base) you would have to know that incompatible changes
were coming in subsequent revisions, or that features of the API that
you rely on will be changed. The upper bound makes perfect sense for
packages that you are maintaining. Perhaps the answer to my original
question is that the maintainer of clash is also maintaining (part of)
On Mon, Jun 6, 2016 at 5:13 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Mon, Jun 6, 2016 at 5:02 PM, Dominick Samperi <djsamperi at gmail.com>
>> Consequently, it refuses to install with the latest ghc provided with
>> the Haskell Platform (8.0.1).
> base is not defined by the Platform, it is defined by (and ships with, and
> must completely match) ghc.
> And no, backward compatibility is not guaranteed; for a recent example, ghc
> 7.10 broke many programs by making Applicative a "superclass" of Monad and
> by generalizing many Prelude functions to Foldable and/or Traversable.
> brandon s allbery kf8nh sine nomine associates
> allbery.b at gmail.com ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
More information about the ghc-devs