- Libraries - Haskell.org

I'm concerned about the affine-types extension and its impact on ghc and haskell at large
by Carter Schonwald 07 Feb '20

07 Feb '20

https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664… https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_lon… As current maintainer of vector, and a member of the CLC, both of which roles really should be AFFIRMATIONAL stakeholders in this, I only see costs and concerns. As someone who's spent the past few years doing a LOT of modelling and prototyping around marrying linear logic, formal methods, and functional programming in an applied industrial setting, i should be an Affirmational stakeholder. yet again I am not. theres very real costs in the complexity and scope of impact that impact EVERY single user and stakeholder of ghc and haskell. And I do not see any concrete population that benefits. cale even makes a very constructive and articulate point > I don't know how much my opinion matters at this point, but I'd really like to see the non-toy real-world use cases of this before I can even consider thinking that it would be a good idea to merge to the main compiler. It has such a huge potential impact on so many people in the Haskell community: > > * Library maintainers who start getting PRs that make "improvements" to linearity while making their libraries harder to maintain because their interface becomes more rigid, and harder to understand because the types are more complicated. > > * Beginners, or simply ordinary users of the language who have to pay the mental overhead of living with the linear types and polymorphism spreading everywhere as types are adjusted to make terms more usable in places where one is concerned with linearity. > > * Commercial users of the language who pay for the additional time taken by all their employees waiting for the compiler to run, regardless of whether or not they're using the extension. If Carter's 6-7% slowdown is real even in cases where one doesn't care about the extension, I can imagine wanting to make a fork without the extension. The compiler is already 2 orders of magnitude slower than I'd like. If that weren't the case, maybe 6-7% wouldn't be a huge deal. While ghci is often helpful at shortening the feedback loop, it's not always a viable solution. > > > But really, I just want to know how anyone would put this to practical use in a real setting -- it needs to be _really_ compelling to make up for the social cost. It can't be that hard for Tweag, or someone enthusiastic, to live on a fork until they have a decent case study to show the world, so we can say "okay, that's actually really cool, maybe we actually want that everywhere".

1 0

add instance PrintfArg Ratio
by Dannyu NDos 07 Feb '20

07 Feb '20

It just is so convenient. instance (Integral a, Show a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then showsPrec 0 x else if elem c "doxXb" then formatArg (round x :: Integer) (f {fmtPrecision = Nothing, fmtChar = 'd'}) else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let n = truncate x sig = '.' : goF (x - fromInteger n) p' b = case a of Just ZeroPad -> formatArg n (f {fmtWidth = fmap (subtract (length sig)) w, fmtPrecision = Nothing, fmtChar = 'd'}) "" _ -> show n in formatArg (b ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e a' = case a of Just ZeroPad -> a _ -> Nothing fp = formatArg q (f {fmtWidth = fmap (subtract (length sig)) w, fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0)

2 1

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

07 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

Fwd: Misleading documentation for `fail`
by Artem Pelenitsyn 07 Feb '20

07 Feb '20

Hello, The fail package [1] lists libraries(a)haskell.org as maintainer's address, so I'm writing here. The documentation for the single module in the package claims: This module can be imported for defining forward compatible MonadFail instances: import qualified Control.Monad.Fail as Fail instance Monad Foo where (>>=) = {- ...bind impl... -} -- Provide legacy fail implementation for when -- new-style MonadFail desugaring is not enabled. fail = Fail.fail ... But defining the fail method inside a Monad instance will produce an error on GHC 8.8+. Should this bit be removed? -- Best, Artem [1]: http://hackage.haskell.org/package/fail

2 1

Read (Ratio a) should also parse a decimal point literal
by Dannyu NDos 05 Feb '20

05 Feb '20

Given a string representing a decimal point literal (ex. "0.25"), the number it represents is guaranteed to be rational. It seems appropriate for Ratio to parse such strings. readDecimalRatio :: (Integral a, Read a) => ReadPrec (Ratio a) readDecimalRatio = parens $ do Number x <- lexP return (numberToRational x) Combine this by (+++) with the original `readPrec` from the instance Read Ratio.

1 0

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

05 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 29 Jan '20

29 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 16 Jan '20

16 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 16 Jan '20

16 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