January 2020 - 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

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 07 Jun '20

07 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

Re: Break `abs` into two aspects
by Andrew Lelechenko 09 Feb '20

09 Feb '20

On Tue, 28 Jan 2020, Dannyu NDos wrote: > `abs` represents a norm, but its type is wrong There are two useful meanings of `abs`, which coincide for integers. One is a norm. Another one is to define `abs` as a mapping from a ring R to a factor ring R / U(R), where U(R) is a ring of units, and `signum` as a mapping from R to U(R) such that `abs a * signum a = a`. > This enables us to implement rings (Num) and fields (Fractional) without > concerning about norms. For example, Gaussian integers. For Gaussian integers I find convenient to define `signum z` with a codomain {1, i, -1, -I} (basically, to which quadrant does z belong?) and `abs z` with the first quadrant as a codomain. Best regards, Andrew

5 20

deepseq: Add more instances. #50
by Travis Whitaker 08 Feb '20

08 Feb '20

Greetings Haskellers, I am writing to draw your attention to https://github.com/haskell/deepseq/pull/50. This PR adds NFData instances for UArray, ForeignPtr, and TVar. The instances for ForeignPtr and TVar have proven to be somewhat controversial. I'll refer to these as "reference types" from here on out, since similar concerns have been raised with respect to e.g. IORef. I think the arguments presented here apply equally well to IORef. In summary: the argument against these instances is that rnf forces the evaluation of the reference value itself, not the value referred to by the reference. This is potentially confusing to NFData users. For example, a user might expect that calling force on a TVar value will leave the value to which the TVar refers in normal form. If this assumption doesn't hold, the user's program will leak thunks. The argument for these instances is as follows: whether or not a reference value is in normal form has nothing to do with whether or not the referred-to value is in normal form. For example, consider ForeignPtr. ForeignPtr's type constructor argument is just a phantom. Each ForeignPtr value is just an Addr# with some finalizers. Whether or not these values are in normal form has nothing to do with whether or not the value the enclosed address may (or may not!) point to is in normal form. Indeed, an NFData instance for ForeignPtr, TVar, or IORef that attempted to force the referred-to value would require unsafe IO. I'm curious to hear other's thoughts about these arguments. I'm hopeful that the proposed instances may be added, since I've encountered these instances as orphans on numerous occasions. Thanks for your time, Travis Whitaker

12 18

Remove MonadFail (ST s) instance
by Oleg Grenrus 06 Feb '20

06 Feb '20

I cannot see any justification for that instance -- | @since 4.11.0.0 instance Fail.MonadFail (ST s) where fail s = errorWithoutStackTrace s If someone wants to fail pattern matches in `ST s`, please do that explicitly. I suggest and propose the removal without any deprecation period. If someone depends on this behavior, they ought to fix they code immediately: it's straight forward compiler type-error driven refactoring. Note: compatibility package https://hackage.haskell.org/package/fail-4.9.0.0/docs/Control-Monad-Fail.ht… doesn't have that instance, so I suspect not-that many use(d) that instance. Discussion period: 2 weeks (until Monday 2019-12-09). - Oleg P.S. you might run into problems with https://gitlab.haskell.org/ghc/ghc/issues/15681 bug/miss-feature, but there's always a workaround to write code using explicit matching combinator, so it's not a show stopper.

14 23

Break `abs` into two aspects
by Dannyu NDos 30 Jan '20

30 Jan '20

This two-step proposal suggests to alter the official Haskell 2010 standard. 1. Introduction: The `Num` typeclass effectively represents a ring. Yet it also has `abs` and `signum`. `abs` represents a norm, but its type is wrong: abs :: a -> a Mathematically, the return value must be a nonnegative real number. Yet there is no guarantee that the type `a` can have that value. This led us to have too strong restriction to `instance Num Complex`: instance RealFloat a => Num (Complex a) where ... I found a way for `abs` (and `signum`) to have much more mathematical place. 2. Step 1: First, I suggest to add the following variants of `abs` and `signum`: realAbs :: Real a => a -> a realAbs x = if x >= 0 then x else negate x realSignum :: Real a => a -> a realSignum x = case compare 0 x of LT -> -1 EQ -> 0 _ -> 1 These can replace `abs` and `signum` instances for integral and rational types. 3. Step 2: Second, I suggest to move `abs` and `signum` from `Num` to `Floating`: class Floating a where abs :: a -> a signum :: a -> a ... This exploits the fact that `Floating` represents a field with characteristic 0, regarding exponential and trigonometric functions are defined as Taylor series. The definition of convergence of series is defined using norms. 4. Conclusion: This enables us to implement rings (Num) and fields (Fractional) without concerning about norms. For example, Gaussian integers.

2 5

[core libraries] Call for Nominations
by George Wilson 17 Jan '20

17 Jan '20

Dear Haskellers, We're putting out a call for new nominations (typically but not necessarily self-nominations) to the Core Libraries Committee. We have one open slot, as Ryan Scott has chosen to step down from the committee. At the same time, Edward Kmett is stepping down from his role as chair. Edward will remain on the committee as a regular member for the duration of his term. Once we have filled Ryan's seat, the committee will decide on a new chair. To nominate yourself to the committee, please send an email to core-libraries-committee at haskell.org by the 17th of February, 2020. 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 a background in organising 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 (cc'd), or contact one of us individually. Kind regards, George Wilson on behalf of the Core Libraries Committee

1 0

Who is on the core libraries committee (CLC)?
by Simon Jakobi 17 Jan '20

17 Jan '20

Hi! Recent emails [1] [2] indicate that the CLC member list [3] is outdated. Could someone clarify who the current members are and who the current Chair is? Cheers, Simon [1] https://groups.google.com/forum/#!topic/haskell-core-libraries/InkZtGOyCgA [2] https://groups.google.com/forum/#!topic/haskell-core-libraries/fTmt22wP6Zg [3] https://wiki.haskell.org/Core_Libraries_Committee#Current_members

4 5

Re: deepseq: Add more instances. #50
by Travis Whitaker 15 Jan '20

15 Jan '20

If the Control.DeepSeq module exports an error-yielding instance, then one would need to newtype all their ForeignPtrs in order to define their own correct NFData instance. Naturally I’m biased, but that seems like quite a hoop to jump through to get correct but subtle behavior. I’m not sure the core libraries go to such lengths to hide correct-but-tricky behavior anywhere else; I’d be interested in seeing existing examples of this. On Wed, Jan 15, 2020 at 1:13 AM Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Wed, 15 Jan 2020, Travis Whitaker wrote: > > > If such an error-yielding instance were added, how would users who need > > the correct-but-potentially-confusing behaving NFData instance cope with > > this? > > In the criterion/record example they would manually implement the NFData > instance for the record, as you already suggested. >

1 0