September 2017 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 13 Aug '20

13 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

Removing bitSize
by David Feuer 05 Feb '18

05 Feb '18

The long-deprecated bitSize method of the Bits class is slated to be removed in base-4.11 (GHC 8.4). There is one remaining question: should we replace it with a *function* by that name with a FiniteBits constraint? I don't feel very strongly either way, but Ryan Scott seems in favor and Edward Kmett seems opposed. So it seems best to bring it to the libraries list and let the CLC make the call. If the function is added, it would look like this: bitSize :: FiniteBits a => a -> Int bitSize = finiteBitSize The biggest downside I see is that we might one day want to reuse the name for something with a better type, such as bitSize :: forall proxy a. FiniteBits a => proxy a -> Int bitSize _ = finiteBitSize (undefined :: a) or bitSize :: forall a. FiniteBits a => Tagged a Int bitSize = Tagged (finiteBitSize (undefined :: a)) or (with type applications) bitSize :: forall a. FiniteBits a => Int bitSize = finiteBitSize (undefined :: a) Thanks, David Feuer

5 5

Maintenance of streaming and streaming-bytestring
by Andrew Martin 11 Dec '17

11 Dec '17

David Feuer brought this up two weeks ago [0]. The maintainer of streaming and streaming-bytestring has been unreachable, and provided his continued absence, I would like to become a maintainer of these two libraries. I have put up PRs fixing issues [1] and I've offered on the issue tracker to become a comaintainer [2]. I use this library a lot at work, so I have an interest in keeping it in good shape. [0] https://mail.haskell.org/pipermail/libraries/2017-August/028141.html [1] https://github.com/michaelt/streaming-bytestring/pull/11 [2] https://github.com/michaelt/streaming-bytestring/issues/19 -- -Andrew Thaddeus Martin

6 12

Re: Deprecating fromIntegral
by Thomas Jakway 26 Sep '17

26 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 20 Sep '17

20 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 15 Sep '17

15 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 11 Sep '17

11 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