January 2018 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 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

Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
by Matt Renaud 05 Jan '19

05 Jan '19

*What* *====* Rename unordered-container's Data.HashMap.lookupDefault <https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-…> to findWithDefault. findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v Note: There are no functionality changes, this is purely a rename. *Why* *===* This aligns the Data.HashMap API with containers' Data.Map.findWithDefault <https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Stric…> . Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a The map APIs provided by the two packages are *almost* drop in replacement compatible if you aren't using any of the implementation specific functions (like ordering based functions from Data.Map), this change brings us one step closer. API consistency reduces the cognitive overhead when learning a new package. Having to learn different function names for the same functionality depending on which "map" implementation you're using is a poor developer experience. We chose the containers' name findWithDefault over unordered-containers' lookupDefault for two reasons: 1. Existing lookupX functions returns a Maybe value, while findX functions return a non-wrapped value. 2. The containers package ships with GHC and is a "core" package. *Pros:* *-----* - Consistent API between different "map" implementations (Data.Map, Data.IntMap, Data.HashMap). This makes switching implementations an import change. - Naming matches other similar functions (lookupX return Maybe-wrapped values) *Cons:* *-----* - API change requires users to update their code + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days) *How* *===* https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13… *Code Changes:* *-------------* - Rename the function in Data.HashMap.Base (and expose it from Strict and Lazy modules) - Make lookupDefault an INLINE alias of findWithDefault - Add DEPRECATION notice to lookupDefault - Bump unordered-containers version to 0.2.9.0 *Migration - Option 1:* *---------------------* *- *Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault with deprecation notice remains for 1 year (subject to change) - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major version bump due to breaking change) *Migration - Option 2:* *---------------------* - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault function is never removed *Discussion: * *===========* I would like to get some comments on this proposal. In particular: - Is the small API churn worth the increase in consistency? - Should migration option 1 (completely remove the old function) or 2 (keep old function indefinitely) be taken? We can punt on this and go with option 2 to start and revisit later if desired. I hope a decision about the proposal can be reached by 2018-02-09. Thanks!

6 10

Re: Storable laws
by Henning Thielemann 07 Mar '18

07 Mar '18

On Sun, 17 Dec 2017, Merijn Verstraaten wrote: > Tools like hsc2hs already pad the result of sizeOf to the appropriately > aligned size (at least the ones I've used), so this is a non-issue for > that scenario. But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.

5 7

Removing bitSize
by David Feuer 04 Feb '18

04 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

Combinators for Show
by Li-yao Xia 30 Jan '18

30 Jan '18

Hello libraries, base contains a small combinator library for Read, but there doesn't seem to be a similar thing for Show. Offering a few more convenient helpers to avoid dealing with whitespace and especially precedence levels seems straightforward enough. Is there an API somewhere that I missed? Has there been a proposal/discussion about this before? I'm ready to make one otherwise. Li-yao

3 3

Name of 1-Tuple Data Type
by Andrew Martin 29 Jan '18

29 Jan '18

Required background information: https://ghc.haskell.org/trac/ghc/ticket/14673 GHC has a one-tuple (both a boxed variant and an unboxed variant). The unboxed variant currently must be fully applied whenever it is used. This is in stark contrast to all the other n-tuples (n > 1). It stems entirely from an issue of syntax. The solution decided on is to provide a normal prefix name for the 1-tuple. The name that GHC uses internally for this type is `Unit#` (there is also a boxed variant Unit). However, in the haskell community, the word "unit" already refers to the nullary tuple, not the unary tuple. So, we're bikeshedding the name. Here are some possible options: * Unary (as in unary tuple) * Single (as in single, double, triple) * Singleton (as is singleton, doubleton, tripleton) * Only ( https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html) * OneTuple ( https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple… ) * Uni (means "one" in latin or greek or something like that) * Mono (means "one" in latin or greek or something like that) I would appreciate any feedback on the suggestions I provided or any additional suggestions for the name. If you have concerns about the feature itself, comment on the GHC Trac ticket. I'd prefer to keep this thread focused on just the problem of coming up with a name. -- -Andrew Thaddeus Martin

13 20

Crazy suggestion for dealing with the naming disaster that is ByteString
by Merijn Verstraaten 28 Jan '18

28 Jan '18

Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything. But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes". Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever. Cheers, Merijn

4 4

Taking over maintainership of exact-pi
by Andrew Lelechenko 27 Jan '18

27 Jan '18

I would like to take over `exact-pi` package (https://hackage.haskell.org/package/exact-pi) Unfortunately, the package became incompatible with upcoming GHC 8.4 and needs an upgrade. The relevant pull request (https://github.com/dmcclean/exact-pi/pull/5) prepared by @konn, has been open for a month without response. I also tried to reach its maintainer Douglas McClean (cced) by email, but have not heard back. I am so interested in upgrading `exact-pi`, because it is a dependency of my package `arithmoi`. — Best regards, Andrew

3 2

Fwd: Re: generalized IntMap - IntegerMap or IntegralMap
by David Feuer 22 Jan '18

22 Jan '18

---------- Forwarded message ---------- From: "David Feuer" <david.feuer(a)gmail.com> Date: Jan 22, 2018 1:42 PM Subject: Re: generalized IntMap - IntegerMap or IntegralMap To: "Oliver Charles" <ollie(a)ocharles.org.uk> Cc: That would help, in theory. But backpack is a bleeding-edge experimental GHC feature, and containers has a long history of striving for relative portability. So for now we need to stick to CPP and whatever other widely-available preprocessors we want. On Jan 22, 2018 1:38 PM, "Oliver Charles" <ollie(a)ocharles.org.uk> wrote: > Would backpack be at all useful here? Seems you want to parameterise the > map by choice of numeric type. > > On 22 Jan 2018 3:59 pm, "David Feuer" <david.feuer(a)gmail.com> wrote: > >> I wish I knew. There are some loose ends that need to be tied up and >> unfortunately I have no sense of whether that's happening. >> >> On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail(a)joachim-breitner.de> >> wrote: >> >>> Hi, >>> >>> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer: >>> > Jonathan S. has been working (on and off) on a wholesale replacement >>> for IntMap. >>> >>> what is the plan here? I am currently in the process of formally >>> verifying IntSet (and later IntMap), so I am curious about what is >>> going to change here. >>> >>> Cheers, >>> Joachim >>> >>> -- >>> Joachim Breitner >>> mail(a)joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>

2 1

generalized IntMap - IntegerMap or IntegralMap
by Henning Thielemann 22 Jan '18

22 Jan '18

I want to use Word32 or Word64 bit patterns as indices for a Map. I have checked that IntMap is more efficient than Map in my application. However, the Haskell 98 report warrants only 30 bits for Int including the sign bit. Is there a generalization of IntMap for Map Integer or (Integral k, Bits k) => Map k or would there be general interest in such a data structure?

4 8