October 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

Deprecate First and Last in Data.Monoid
by Andrew Martin 13 Jun '20

13 Jun '20

I propose that the data types First and Last, provided by Data.Monoid, be marked deprecated in GHC 8.6 and removed in GHC 8.10. The Semigroup-Monoid Proposal (SMP) brought about changes that, I will argue, make these data types (1) unneeded and (2) confusing. Why are they no longer needed? Data.Semigroup provides two identically named data types (First and Last). These have Semigroup instances matches what their names suggest. Additionally, SMP corrects the Monoid instance for Maybe so that it now lifts Semigroup instances instead of Monoid instances. What this means is that, assuming the following imports: import qualified Data.Monoid as M import qualified Data.Semigroup as S We have the following equivalences: M.First a === Maybe (M.First a) M.Last a === Maybe (M.Last a) When I say "equivalence", I mean that their Monoid instances have the same behavior. Their Show/Read instances are certainly different, and I’m not sure about their Ord instances. Getting back to the second reason, removing these data types would eliminate confusion. It’s strange that Semigroup is a superclass of Monoid, yet they have Data types with conflicting names defined in their respective modules. When you see the data type First, you cannot tell what someone is talking additional context. In general, base strives to avoid duplicate identifiers. The only other exception to this rule I can think of is that Bifunctor and Arrow both use the identifiers first and second. But, the situation with Data.Semigroup and Data.Monoid is higher impact since people are more likely to import these modules unqualified together. (As an aside, and the confusion I’m talking about here isn’t entirely hypothetical. I got tripped up by this when I first started using the semigroups library. I had to train myself to stop importing Data.Monoid unqualified, because it kept stealing these identifiers) Again, the two reasons are that these are no longer necessary and that they cause confusion. I would appreciate any feedback, including simple nods of agreement or disagreement. Thanks. -- -Andrew Thaddeus Martin

7 8

Contacting bytestring-trie maintainers
by Tim McGilchrist 07 Feb '19

07 Feb '19

Hi All, I am trying to get in touch with the maintainers for bytestring-trie package ( http://hackage.haskell.org/package/bytestring-trie ), which appears to be Wren Romano. I have a patch to fix issues with GHC 8.4 support. I have sent 2 emails over the last few months using the contact details in the cabal file and haven’t received a reply. Email attached below. Could I ask if someone has a better contact address or is able to pass on the email that they would. Failing that I’d like to get access to push the fix to hackage without the need for making a forked package. Cheers, Tim McGilchrist ——————————————————— Hi Wren, I'm using your bytestring-trie library in a package (airship) and wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. Please find attached a minor patch to add support which is mainly concerned with adding the Semigroup instances required. If you're happy with the changes I'd also appreciate a new release of the package to hackage. Regards, Tim McGilchrist

4 7

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

Whither split base?
by Carter Schonwald 23 Nov '18

23 Nov '18

I just remembered that it was one of the ongoing things the CLC was involved with, for a while. Has there been recent action there ?

13 36

Taking over maintainership of cpphs, HaXml, hscolour, and polyparse
by Peter Simons 05 Nov '18

05 Nov '18

Fellow Haskell Hackers, it appears that Malcolm Wallace has lost interest in maintaining his packages on Hackage. Some of them are rather important dependencies for others, and therefore I'd like to take over maintenance of the following libraries: - cpphs - HaXml - hscolour - polyparse Polyparse, in particular, needs a maintenance update to fix build issues with GHC 8.6.1. The absence of a working release blocks packages like hlint from supporting that compiler [1]. I tried to contact Malcolm on 2018-09-24 via e-mail. Others have also tried to reach him through WhatsApp other channels. Unfortunately, no-one has received a response, which is why we decided to go through with this process. Best regards, Peter [1] https://github.com/haskell-infra/hackage-trustees/issues/186

11 13

Proposal: give Ptr a nominal role
by David Feuer 04 Nov '18

04 Nov '18

Currently, we have data Ptr a = Ptr Addr# type role Ptr phantom This is weird: accidentally coercing a pointer to a different type is very bad. The only reason Ptr has this role is that without it, castPtr and such may not be free or will involve unsafe coercions. Thankfully, we have enough power to fix this now. data Addr = Ptr_ Addr# newtype Ptr a = Ptr_ Addr type role Ptr nominal pattern Ptr :: Addr# -> Ptr a pattern Ptr a# = Ptr_ (Addr a#) castPtr :: Ptr a -> Ptr b castPtr (Ptr a) = Ptr a ptrCoercible :: ((forall a b. Coercible (Ptr a) (Ptr b)) => r) -> r ptrCoercible r = r ptrCoercion :: Coercion (Ptr a) (Ptr b) ptrCoercion = Coercion I propose that we do this.

7 19

Proposal: Move primitive-Data.Primitive.Addr API into base
by Daniel Cartwright 03 Nov '18

03 Nov '18

Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.

11 86

[core libraries] Call for Nominations
by Edward Kmett 31 Oct '18

31 Oct '18

Dear Haskellers, I'm putting out a call for new nominations (typically but not necessarily self-nominations) to the Core Libraries Committee. We've had two open slots for a while, and technically at least a couple of members of the committee are due to rotate off. To nominate yourself, please send an email to core-libraries-committee at haskell.org by December 1, 2018. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The core libraries committee acts as the maintainer of the core libraries mentioned on https://wiki.haskell.org/Library_submissions For the most part members maintain individual libraries under the maintainer guidelines for Haskell, but there are occasional "barn-raising" style calls for discussion and decision whenever things need a broad enough mandate. We seek a broad representation from different segments of the Haskell world -- including but not limited to those focused on education, those focused on industrial applications, those with background in organizing users-groups, and those focused directly on our technical infrastructure. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Core_Libraries_Committee If you have any questions about the process, please feel free to e-mail us at core-libraries-committee at haskell.org, or contact one of us individually. -Edward Kmett

3 2

Fwd: Proposal: Implement minimumOn, maximumOn to mirror sortOn
by Gabriel Garcia 30 Oct '18

30 Oct '18

Hello, I have a small proposal for review here: https://phabricator.haskell.org/D5110 I'd like to start the discussion on whether this is a useful/acceptable addition the core library. Thanks, - Gabriel

4 3