March 2020 - Libraries

Improving the instances of Data.Functor.{Product,Sum}
by chessai . 25 Jan '21

25 Jan '21

Consider the Eq instance for these types. Currently we rely on: (Eq1 f, Eq1 g, Eq a) But some potential improvements include changing to: (Eq (f (g a))) (FlexibleContexts) or (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a) (QuantifiedConstraints) There was a discussion sometime last year about the same thing regarding Semigroup/Monoid instances for `Compose` [1]. Additionally, the question has been raised again for Data.Functor.{Product,Sum} on Gitlab [2, 3]. There has been no consensus in either case, but that's not too worrying as both discussions have been brief. I'm currently not happy with the {Eq,Ord,Show}{1,2} family of classes, and would hope to work toward their removal, or at least the shrinking of their presence in base. Even though the linked proposals are about a single type, I think it's important that we come up with a decision and stick with it. Having different APIs for different types here would be pretty confusing, and some could even say sloppy. Please let me know your thoughts. [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704

10 22

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

Re: [core libraries] Adding Backwards to base, re-export from Control.Applicative
by Baldur Blöndal 06 Jun '20

06 Jun '20

I'll CC Haskell Libraries þri., 12. nóv. 2019 kl. 22:14 skrifaði Ryan Scott <ryan.gl.scott(a)gmail.com>: > This discussion definitely belongs on the mailing list, yes. > > Ryan > > On Tue, Nov 12, 2019 at 11:59 AM chessai . <chessai1996(a)gmail.com> wrote: > >> I support this. +1 >> >> Should we copy in the libraries mailing list? >> >> On Tue, Nov 12, 2019, 5:56 AM Baldur Blöndal <baldurpet(a)gmail.com> wrote: >> >>> Is it time to move Control.Applicative.Backwards module from >>> transformers to base, and maybe re-export it from Control.Applicative. >>> >>> It's an interesting, important, simple property of Applicative that they >>> can be run backwards. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-core-libraries" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3…> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg… >> <https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg…> >> . >> >

8 7

What do you assume when you see fromListN in a library?
by Carter Schonwald 23 May '20

23 May '20

Hey everyone: When you see fromListN as a function in a library, do you assume / presume it’s expecting an exactly N element list ? Or do you expect/tolerate other behavior ? Should it reject shorter lists? Should it truncate or reject longer lists? A corner case of this came up in some bug discussion I was having regarding vector, and I shall claim and or presume that most folks assume exact size with prompt rejection of too long or too short. Thoughts please ? -Carter

13 32

Adding new contructors to IOMode to support "don't overwrite if already exists" behavior
by Grey Mitchell 22 May '20

22 May '20

The current behavior for System.IO.openFile will either truncate an existing file (with WriteMode) or append new content to the end (with AppendMode). However, there's another behavior that's available from the underlying API: signal an error when the file already exists. I poked around at the code and i think that with a couple extra variants of IOMode, this behavior could be added with a relatively small patch. I have a branch pushed where i added this behavior: https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c37… I'm a relative newcomer to contributing to GHC or the base library, so if i'm missing something in my patch please let me know. Specifically, i would like to know is there's a place i can add a test for this behavior. I'm also open to changing the names of the new IOModes - this was just something i wrote in to get something working. Looking forward to working with maintainers to get this added! Thanks, Grey Mitchell (@QuietMisdreavus)

5 8

Re: intent to enable 2fa requirement for github.com/haskell org
by Carter Schonwald 25 Mar '20

25 Mar '20

Yeah, there’s def an incredible diversity of tools that are great in this space. And there’s at this point decent tools for almost every platform constraint imaginable. On Wed, Mar 25, 2020 at 1:30 PM Giorgio Marinelli <giorgio(a)marinel.li> wrote: > I use the following 2fa tools. They offer also import/export > functionalities. > > - andOTP (Android) https://github.com/andOTP/andOTP > - OTPClient (Linux) https://github.com/paolostivanin/OTPClient > > Regards, > > > Giorgio > > On Wed, 25 Mar 2020 at 17:48, Carter Schonwald > <carter.schonwald(a)gmail.com> wrote: > > > > Duncan, David, please figure out 2fa tools that work for you and enable > them, > > > > > > https://github.com/tadfisher/pass-otp > > > > https://github.com/solokeys/solo > > > > https://github.com/herrjemand/awesome-webauthn#hardware-authenticators > > > > https://1password.com/ > > > > https://keepass.info/download.html > > > > > > if you are having trouble figuring out tools you're comfortable using, > please share with us those constraints we can help you! > > > > im here to help (and i'm delaying enabling another day or two to provide > help to some active contributors who are having their own difficulties > setitng up this stuff) > > > > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan(a)dcoutts.me.uk> > wrote: > >> > >> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote: > >> > hey everyone, because so much important stuff for the community, it > >> > makes sense to add 2fa required for the org, are there any good > >> > reasons to either wait to do this, or not do it? Feedback welcome! > >> > >> I think I might get cut off. > >> > >> Is it not still the case that github's 2fa needs a program running on a > >> mobile phone, or an SMS-capable mobile phone? Is there any support for > >> normal tools running on a normal Linux machine? > >> > >> (I think last time I tried to use the SMS route, it refused to send SMS > >> messages to my landline, despite the fact that I can receive them) > >> > >> > >> Duncan > >> > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

1 0

Re: intent to enable 2fa requirement for github.com/haskell org
by Carter Schonwald 25 Mar '20

25 Mar '20

Duncan, David, please figure out 2fa tools that work for you and enable them, https://github.com/tadfisher/pass-otp https://github.com/solokeys/solo https://github.com/herrjemand/awesome-webauthn#hardware-authenticators https://1password.com/ https://keepass.info/download.html if you are having trouble figuring out tools you're comfortable using, please share with us those constraints we can help you! im here to help (and i'm delaying enabling another day or two to provide help to some active contributors who are having their own difficulties setitng up this stuff) On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan(a)dcoutts.me.uk> wrote: > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote: > > hey everyone, because so much important stuff for the community, it > > makes sense to add 2fa required for the org, are there any good > > reasons to either wait to do this, or not do it? Feedback welcome! > > I think I might get cut off. > > Is it not still the case that github's 2fa needs a program running on a > mobile phone, or an SMS-capable mobile phone? Is there any support for > normal tools running on a normal Linux machine? > > (I think last time I tried to use the SMS route, it refused to send SMS > messages to my landline, despite the fact that I can receive them) > > > Duncan > >

1 0

Export functions on Natural in Numeric.Natural
by Zemyla 22 Mar '20

22 Mar '20

Functions in GHC.Natural like naturalToWordMaybe and minusNaturalMaybe are extremely useful, especially when trying to write provably total functions, and I wish they were available in a Safe module like Numeric.Natural. I also want a total function that does the following: -- This function turns an Integer n into a pair of -- (fromInteger (abs n), fromInteger (signum n)). integerToNaturalSign :: Integer -> (Natural, Int) #if 0 -- This is the reference version, except for the fact that numeric literals don't exist yet -- when GHC.Natural is being defined, and fromInteger isn't actually total. integerToNaturalSign n = case compare n 0 of LT -> (fromInteger (negate n), -1) EQ -> (0, 0) GT -> (fromInteger n, 1) #elif !defined(MIN_VERSION_integer_gmp) -- This is like the reference version, except using the newtype wrapper and MagicHash. integerToNaturalSign n = case compare n (intToInteger# 0#) of LT -> (Natural (negateInteger n), I# (-1#)) EQ -> (Natural n, I# 0#) GT -> (Natural n, I# 1#) #else -- We take advantage of the GMP functions and constructors. integerToNaturalSign (Jn# bn) = (bigNatToNatural bn, I# (-1#)) integerToNaturalSign (S# i#) = case isTrue# (i# <# 0#) of True -> (NatS# (int2Word# (negateInt# i#)), I# (-1#)) _ -> (NatS# (int2Word# i#), I# (i# ># 0#)) integerToNaturalSign (Jp# bn) = (bigNatToNatural bn, I# 1#) #endif

2 3

Alternative instance for Const
by chessai . 22 Mar '20

22 Mar '20

We already have instance Monoid m => Applicative (Const m) we could easily add instance Monoid m => Alternative (Const m) where empty = coerce mempty (<|>) = coerce (<>) which trivially satisfies left/right identity and associativity. I propose we add this instance to base.

5 5