On 20 Jan 2015, at 11:20, Björn Peemöller wrote:
The reason is the usage of foldr, which changed its type from
foldr :: (a - b - b) - b - [a] - b -- GHC 7.8.4
to
foldr :: Foldable t = (a - b - b) - b - t a - b -- GHC 7.10.1
Thus, the use of foldr is now ambiguous. I can fix this by
There is a limited set of situations where the new signatures can fail to
infer, where it would infer before.
This can happen when you construct a Foldable/Traversable value using
polymorphic tools (like Read) that were previously instantiated for list,
but where since foldr et al. are now
I just discovered that the following program compiled fine using GHC
7.8.4 but was rejected by GHC 7.10.1-rc1:
~~~
data List a = Nil | Cons a (List a)
instance Read a = Read (List a) where
readsPrec d s = map convert (readsPrec d s)
where
convert (xs, s2) = (foldr Cons Nil xs, s2)
~~~
On Tue, Jan 20, 2015 at 6:45 PM, Edward Kmett ekm...@gmail.com wrote:
I can at least say that the incident rate for cases seems to be very low,
especially when it is contrasted against the pain users have had with using
the existing Foldable/Traversable imports where virtually everything in
On Tue, Jan 20, 2015 at 9:00 AM, Kim-Ee Yeoh k...@atamo.com wrote:
There are few reports because the change hasn't affected the dark majority
yet. RC builds are used by a tiny fraction. There's a long tail of users
still on 7.6, 7.4, 7.2, and 6.x.
We've been actively testing since the
I like this proposal: if you're explicit about an import that
would otherwise be implicit by Prelude, you shouldn't get a
warning for it. If it is not already the case, we also need to
make sure the implicit Prelude import never causes unused import
errors.
Edward
Excerpts from Edward Kmett's
I was assuming that the list was generated by doing more or less the same
check we do now. I haven't looked at the code for it.
If so, then it seems it wouldn't flag a now-unnecessary Data.Traversable
dependency for instance. At least not without rather significant retooling.
I might be off in
It isn't without a cost. On the down-side, the results of
-ddump-minimal-imports would be er.. less minimal.
On Tue, Jan 20, 2015 at 6:47 PM, Edward Z. Yang ezy...@mit.edu wrote:
I like this proposal: if you're explicit about an import that
would otherwise be implicit by Prelude, you
On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel h...@gnu.org wrote:
I'm a bit confused, several past attoparsec versions seem to build just
fine with GHC 7.10:
https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
were there hidden breakages not resulting in compile errors?
Sure.
Adding it to the CHANGELOG makes a lot of sense. I first found out about it
only a few weeks ago when Herbert mentioned it in passing.
Of course, the geek in me definitely prefers technical fixes to human ones.
Humans are messy. =)
I'd be curious how much of the current suite of warnings
Hello Bryan,
On 2015-01-20 at 23:17:01 +0100, Bryan O'Sullivan wrote:
[...]
For the record, it took me almost an hour to update attoparsec to fix all
the various regressions, or to put it more charitably changes, introduced
in GHC 7.10. I have twenty-something other packages to go through. I
I don't see why that would be the case: we haven't *excluded* any
old import lists, so -ddump-minimal-imports could still
take advantage of Prelude in a warning-free way.
Edward
Excerpts from Edward Kmett's message of 2015-01-20 16:36:53 -0800:
It isn't without a cost. On the down-side, the
Building -Wall clean across this change-over has a big of a trick to it.
The easiest way I know of when folks already had lots of
import Data.Foldable
import Data.Traversable
stuff
is to just add
import Prelude
explicitly to the bottom of your import list rather than painstakingly
exclude
On 2015-01-21 at 00:27:39 +0100, Edward Z. Yang wrote:
Hello Edward,
Shouldn't we publicize this trick? Perhaps in the changelog?
Fwiw, I've added that workaround/recipe to
https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant
feel free to improve the
14 matches
Mail list logo
