Changes to base(3)

Changes to base:
commit cd00135acbdfaae3adab2b5acf14386eddde9fa8
Author: Herbert Valerio Riedel <hvr@gnu.org>
Date:   Thu Jun 26 10:07:18 2014 +0200

    Bump to 4.7.0.1 and update changelog.md

    Fwiw, the version bump should have been performed together with the first
    change after 4.7.0.0

    Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

commit 4254e158e05ac86b922dea6ba3c3c330732d991b
Author: Herbert Valerio Riedel <hvr@gnu.org>
Date:   Tue Jun 24 22:58:41 2014 +0200

    Fixup c1035d51e to behave more like in GHC 7.6

    The fix in c1035d51e (addressing #9231) was done under the assumption
    that `Data.Fixed` is used only with power-of-10 `resolution`. This
    follow-up fixup changes the behavior to be more consistent with the
    previous behavior in GHC 7.6

    For instance, for the following `B7` resolution

       > data B7
       > instance HasResolution B7 where resolution _ = 128

    After this patch, the following behavior is now observable:

       > 1.070 :: Fixed B7
       1.062
       > 1.062 :: Fixed B7
       1.054

       > read "1.070" :: Fixed B7
       1.062
       > read "1.062" :: Fixed B7
       1.054

    This doesn't provide the desirable "read . show == id" property
    yet (which didn't hold in GHC 7.6 either), but at least `fromRational`
    and `read` are consistent.

    Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

    (cherry picked from commit [ec550e8f951e50fb91c89389e2e77a3358079c3a/ghc])

commit 99462b6877308003442942cbddb3296f29cfb9a8
Author: Herbert Valerio Riedel <hvr@gnu.org>
Date:   Tue Jun 24 11:42:06 2014 +0200

    Fix regression in Data.Fixed Read instance (re #9231)

    `convertFixed` operates under the wrong assumption that
    `Data.Fixed.resolution` returns a base-10 exponent `e`, whereas it
    actually returns the power-of-10 value `10^e`.

    So while the code (that was introduced in 5f19f951d8 / #7483) happens to
    compute a correct result by coincidence, it allocates huge integer values
    in the process (i.e. `10^(10^e)`) which cause long computations which
    eventually result in out-of-memory conditions for `e`-values beyond
    `Data.Fixed.Milli`.

    A proper long-term fix would probably be to extend the `HasResolution`
    type-class to have a 2nd method providing the `e` value.

    Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

    (cherry picked from commit [c1035d51edaac2f388a0630e2ad25391e7e3c1ab/ghc])

    Differential Revision: https://phabricator.haskell.org/D25