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 word
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 my
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 res
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 wrote:
> I like this proposal: if you're explicit about an import that
> would otherwise be implicit by Prelude, you shouldn't get a
> wa
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 m
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 c
Hello Edward,
Shouldn't we publicize this trick? Perhaps in the changelog?
Edward
Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> 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
>
> impor
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 the
On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel 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?
> Or are
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.
On Tue, Jan 20, 2015 at 3:45 AM, Edward Kmett wrote:
> Ultimately, there is, of course, a balancing act between flexibility and
> inference.
>
> 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
On Tue, Jan 20, 2015 at 9:00 AM, Kim-Ee Yeoh 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 first time we
On Tue, Jan 20, 2015 at 6:45 PM, Edward Kmett 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
> them collided
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 polymor
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 fi
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)
~~~
16 matches
Mail list logo
