- Libraries - Haskell.org

Re: Deprecating fromIntegral
by Thomas Jakway 25 Sep '17

25 Sep '17

I can see both sides of this and am dismayed. On the one hand, -Wall literally means with all warnings--so it makes sense to pack as many warnings as possible into it. If that's too many warnings for the end user, they can disable individual ones when looking through the output. If we wanted to be really thorough we could provide a suggestion at the end of the output ("90% of your warnings are from ____"). On the other hand, grep -I -R --include="*.hs" "fromIntegral" | wc -l on ghc prints 2598, which is a lot. For what it's worth I'm in favor of adding it to -Wall because I would rather be warned about too many things and have to force myself not to ignore them than spend a long time figuring out the source of a bug. At the very least when I do encounter a bug it'll give me somewhere to start. There's no great solution here, only tradeoffs. I won't lose any faith in Haskell whichever route we take. On 09/22/2017 02:53 PM, Evan Laforge wrote: > On Thu, Sep 21, 2017 at 4:19 PM, Niklas Hambüchen <mail(a)nh2.me> wrote: >> On 21/09/17 19:27, Evan Laforge wrote: >>> If I were to suddenly get 10,000 lines of warnings... >> If the built tool is set up sensibly (perhaps we should make it so if >> that is not already possible, but I think these days warnings of >> dependency packages are omitted anyway, as cabal and stack build them in >> parallel), you should get (and care about and fix) only warnings about >> those occurrences that are in the packages you maintain / build directly. > I mean dependencies within the project, not external packages. If > modify something in the middle of the dependency tree, I'll be usually > recompiling (say) a couple of hundred modules, for my personal > medium-ish project. I assume in a real company with a larger codebase > you could easily be recompiling thousands. Maybe just the mono-repo > ones though. > > Also I'm assuming most code is not in packages, and is not in hackage. > I have no real basis for that, other than experience with other > languages. But, as shown below, my guesses can be pretty wrong: > >> Most packages have < 3 occurrences of fromIntegral, a few have < 20 >> occurrences. Very few have more than 20. >> >> Assuming we go for a naming improvement and add 3 functions ala >> maybeFromInteger / runtimeCheckedFromInteger / fromIntegerWrap, a >> package owner would have to step through their deprecation warnings and >> replace each with one of the new 3 functions to get their package >> warning-free. > I'm surprised about that, I assumed more. Grepping for fromIntegral > in a local project, I get 259 occurrences over 693 modules... I > expected a lot more. > > However, a lot of those I think would be false positives, because > they're converting across newtypes, where the underlying type is the > same. I'm not sure what I would use for those... I guess it would be > fromIntegerWrapped, but it's kind of verbose and awkward and is > implying wrapping when it's not actually present. Maybe they should > be using 'coerce'? Most of them existed before coerce did, but that's > not an excuse any more. I think I'd be more likely to try out > int-cast. > >> I could probably already have fixed 1000 of the 7000 total occurrences >> on Hackage myself within the time it as taken me to debug integer >> conversion related problems in GHC/base in the last week. >> >> (In other words, these changes are cheap and have high payoff.) > Of course that's the bottom line, so if it's the case then it's hard > to argue against. > > I've had similar bugs due to sloppy haskell -> C FFI conversions so > I'm sympathetic to the idea. It's just a blanket deprecation on > fromIntegral seems like a broad brush. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Re: Deprecating fromIntegral
by dominic＠steinitz.org 22 Sep '17

22 Sep '17

> On 22 Sep 2017, at 13:43, Dominic <dominic.steinitz(a)blueyonder.co.uk> wrote: > > Coincidentally, I was playing with this a few days ago. I didn’t seem to have to do anything to get a warning. > >> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >> Prelude Data.Word> :m Data.Int >> Prelude Data.Int> 0x80000000 :: Int32 >> >> <interactive>:27:1: warning: [-Woverflowed-literals] >> Literal 2147483648 is out of the Int32 range -2147483648..2147483647 >> If you are trying to write a large negative literal, use NegativeLiterals >> -2147483648 >> Prelude Data.Int> :set -XNegativeLiterals >> Prelude Data.Int> 0x80000000 :: Int32 >> >> <interactive>:29:1: warning: [-Woverflowed-literals] >> Literal 2147483648 is out of the Int32 range -2147483648..2147483647 >> -2147483648 > > I am not clear why it wanted me to use NegativeLiterals but still give the same warning. Does anyone understand the intent here? > >> Message: 1 >> Date: Fri, 22 Sep 2017 14:14:12 +0200 >> From: Herbert Valerio Riedel <hvriedel(a)gmail.com> >> To: Niklas Hambüchen <mail(a)nh2.me> >> Cc: Haskell Libraries <libraries(a)haskell.org> >> Subject: Re: Deprecating fromIntegral >> Message-ID: >> <CAOFsArv1rDT1=KsM_z1vDOf_CW-jamOT8nzGzHk3VnxuEvjMug(a)mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> ...there's one minor detail I'd like to point out as it doesn't seem >> to have been mentioned so far: >> >> On Thu, Sep 21, 2017 at 5:34 PM, Niklas Hambüchen <mail(a)nh2.me> wrote: >> >>> (Though, in practice the current `fromInteger is not partial, e.g. >>> `(fromInteger 256 :: Word8) == 0` without error >> >> That's true. However, here's something you can do already now with >> recent GHCs which gives turns literal-overflows GHC is able to detect into >> hard compile errors: >> >> >> $ ghci -Wall -Werror=overflowed-literals >> GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help >> Prelude> (256 :: Data.Word.Word8) == 0 >> >> <interactive>:1:2: warning: [-Woverflowed-literals] >> Literal 256 is out of the GHC.Word.Word8 range 0..255 >> >> <no location info>: error: >> Failing due to -Werror. >> Prelude> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> ------------------------------ >> >> End of Libraries Digest, Vol 169, Issue 30 >> ****************************************** > Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Proposal: Bring the Contravariant class to base
by Daniel Díaz Casanueva 19 Sep '17

19 Sep '17

Dear haskellers, I admit I might not have the strongest arguments here, but I thought that I would share my opinion anyway, and maybe get other people's perspectives. I would like to propose bringing the Contravariant class [1] to base. I know, base keeps growing, and maybe there is no need for it to grow further without a strong argument, but I do feel like Contravariant is a simple, very basic class, that would receive better and greater use if included in base. Contravariant is very similar to Functor (some people call it CoFunctor), but in `contramap` (Contravariant's `fmap`) the "arrow" of the applied function goes in the opposite direction. I think that `contramap` can be useful for many types, just like `fmap` is for many others, but we don't use it because it's not yet so popular, or maybe because it requires the contravariant package to be included as dependency (although personally I don't think that is a real problem). The contravariant package itself provides a plentiful of instances, many of them for types in base. In a real world scenario I had, it was very useful to add a Contravariant instance to `Data.Aeson.ToJSONKeyFunction`, that perhaps is not included in aeson because either it was not desired to add the contravariant package as dependency, or simply because Contravariant is not so well-known. Note that, however, `FromJSONKeyFunction` _is_ instance of Functor. Even though both instances are equally natural and useful in this context, only one of them was implemented. This probably would not have happened if Contravariant was in base. So, in my opinion, for the sake of completeness, I think we should add Contravariant to base, just as we have Functor. Note that my proposal does not necessarily include the rest of types and functions defined in the contravariant package. Best regards, Daniel Casanueva # References [1] http://hackage.haskell.org/package/contravariant-1.4/docs/Data-Functor-Cont…

13 16

Re: [Haskell-cafe] Maintenance of streaming and streaming-bytestring
by Andrew Martin 14 Sep '17

14 Sep '17

If I can do that with a hackage revision, i'll go ahead and do that tonight. If not, there will probably be a new release for both of them in the next week anyway, so I would just wait until then to do it. Sent from my iPhone > On Sep 14, 2017, at 6:08 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > >> On 2017-09-13 19:31, Andrew Martin wrote: >> The streaming and streaming-bytestring libraries are now being >> maintained here: https://github.com/haskell-streaming >> > > You might want to upload a new package to Hackage with a change of URL > :). The Hackage package currently points to the old GitHub. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

An IsString (NonEmpty Char) instance
by Artyom 13 Sep '17

13 Sep '17

7 12

Bug in the documentation of (<**>)
by Wolfgang Jeltsch 11 Sep '17

11 Sep '17

Hi! The documentation of (<**>) says: “A variant of <*> with the arguments reversed.” In my opinion, this means that (<**>) = flip (<*>). However, this is not true, since (<**>) does not change the order of effects. The actual definition of (<**>) is a <**> f = liftA2 (\ x h -> h x) a f. Could this please be fixed? All the best, Wolfgang

2 1

FunctorFix
by Wolfgang Jeltsch 10 Sep '17

10 Sep '17

Hi! There is the MonadFix class with the mfix method. However, there are situations where you need a fixed point operator of type a -> f a for some f, but f is not necessarily a monad. What about adding a FunctorFix class that is identical to MonadFix, except that it has a Functor, not a Monad, superclass constraint? All the best, Wolfgang

5 18

Proposal: Rework Data.Type.Equality.==
by David Feuer 08 Sep '17

08 Sep '17

The discussion has been going for nearly a month, but I've only really gotten feedback from Richard and Ryan Scott (which was both positive and useful). Based on that feedback, I'd like to make this an official proposal and get some votes. Be it proposed that Data.Type.Equality shall be redefined as follows: type family (a :: k) == (b :: k) :: Bool where f a == g b = f == g && a == b a == a = 'True _ == _ = 'False Unlike the previous definition: 1. (==) is a *closed* type family. 2. It works out of the box for types of all kinds, in a completely uniform manner. 3. It is now safe to conclude in all cases that (a == b) ~ 'True entails a ~ b, although GHC will not give us direct evidence of that. Since all the ad hoc instances and special cases are gone, there will be cases in which the previous definition will reduce and this one will not, and vice versa. But there was no particular rhyme or reason to the way it used to be, and I think that making everything simple and uniform is worth the (likely minor) breakage. David Feuer

2 1

Re: Let's rework Data.Type.Equality.==
by Ryan Scott 05 Sep '17

05 Sep '17

Personally, I'd be more inclined towards latter approach (in https://phabricator.haskell.org/D3837) After all, one of the key properties of (==) (for which the Haddocks even make a special note) is that it does not attempt to provide an instance that works for every possible kind. Indeed, as you've discovered, there are cases when it doesn't make sense to use DefaultEq, such as for (). I'll tentatively give my support for D3837, although I'd be curious to hear what Richard has to say about this (since I'm reasonably confident he gave (==) its current implementation). Ryan S.

5 8

Let's rework Data.Type.Equality.==
by David Feuer 01 Sep '17

01 Sep '17

The (==) type family in Data.Type.Equality was designed largely to calculate structural equality of types. However, limitations of GHC's type system at the type prevented this from being fully realized. Today, with TypeInType, we can actually do it, replacing the boatload of ad hoc instances like so: type (a :: k) == (b :: k) = Equal k a b infix 4 == type family Equal (k :: Type) (a :: k) (b :: k) where Equal k ((f :: j -> k) (a :: j)) ((g :: j -> k) (b :: j)) = Equal (j -> k) f g && Equal j a b Equal k a a = 'True Equal k a b = 'False This == behaves in a much more uniform way than the current one. I see two potential causes for complaint: 1. For types of kind *, the new version will sometimes fail to reduce when the old one succeeded (and vice versa). For example, GHC currently accepts eqeq :: forall (a :: *). proxy a -> (a == a) :~: 'True eqeq _ = Refl while the proposed version does not. 2. Some users may want non-structural equality on their types for some reason. The only example in base is type instance (a :: ()) == (b :: ()) = 'True which consists two types of kind () the same even if they're stuck types. But perhaps someone wants to implement a non-trivial type-level data structure with a special notion of equality. I don't think (1) is really worth worrying too much about. For (2), if users want to have control, we could at least use a mechanism similar to the above to make the obvious instances easier to write.

2 6