- Libraries - Haskell.org

Expired certificate for prime.haskell.org
by Simon Jakobi 02 Nov '19

02 Nov '19

Hi! I just wanted to give someone a link to the Semigroup-Monoid-proposal, but couldn't open the page in Chromium: https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid There's already a short email thread regarding the issue from April on the haskell-prime mailing list: https://mail.haskell.org/pipermail/haskell-prime/2019-April/004448.html It would be nice if proposals like the SMP remained accessible! Cheers, Simon

2 3

bitSize both required and deprecated
by chessai . 02 Nov '19

02 Nov '19

All, In Data.Bits.Bits, `bitSize` has been marked deprecated for a while. but in 4.12, it was also given a default implementation. The issue is that it is in the minimal pragma as a required method. So, if I define it, I get a deprecation warning, but if I don't define it, I get a warning about missing implementations. Is this the intended behaviour? Thanks

4 3

Is join useful for every monad?
by Dannyu NDos 15 Oct '19

15 Oct '19

join is surely useful for Maybe and []. But IO (IO a)? ReadPrec (ReadPrec a)? ST s (ST s a)? When the heck could I encounter such types?

7 8

Add instance Storable Ordering
by Dannyu NDos 09 Oct '19

09 Oct '19

7 8

Publicly exported pattern synonym for Ratios?
by Zemyla 03 Oct '19

03 Oct '19

Using the numerator and denominator functions in Data.Ratio adds an extra layer of laziness to functions that have to work with Ratios (especially Rationals). I think it'd be convenient if there were a pattern synonym exported from the safe Data.Ratio: pattern n :% d <- (n GHC.Ratio.:% d) where n :% d = n % d This way, destructuring is as fast as if you were to import GHC.Ratio directly, but it can't be used to create invalid Ratios. The only disadvantage is that using the :% to destructure it requires an Integral constraint on the value, but 99% of the time, the value will be Integer anyway, and even in the remaining 1% you still can't construct a Ratio a without an Integral a constraint in safe code anyway, so it shouldn't matter.

2 1

Package take over: regex-{base,compat,pcre,posix}
by Herbert Valerio Riedel 24 Sep '19

24 Sep '19

Hello everyone, I tried to contact Christopher Kuklewicz on May 10, 2019 via the two email addresses associated with his packages (also CC'ed in this email) but got no response. I hereby invoke the protocol as per https://wiki.haskell.org/Taking_over_a_package to take over the packages mentioned in the subject line which haven't seen any release to Hackage since May 2012 as the most recent upload events for these packages show: 2012-05-30T21:44:34Z ChrisKuklewicz regex-pcre-0.94.4-r0 2012-05-20T16:46:16Z ChrisKuklewicz regex-pcre-0.94.3-r0 2012-05-20T16:35:59Z ChrisKuklewicz regex-posix-0.95.2-r0 2011-05-09T18:01:58Z ChrisKuklewicz regex-compat-0.95.1-r0 2011-05-09T15:55:55Z ChrisKuklewicz regex-posix-0.95.1-r0 2011-05-09T15:29:42Z ChrisKuklewicz regex-posix-0.95.0-r0 2010-07-20T10:58:10Z ChrisKuklewicz regex-posix-0.94.4-r0 2010-06-11T23:01:36Z ChrisKuklewicz regex-posix-0.94.2-r0 2010-06-11T23:00:42Z ChrisKuklewicz regex-pcre-0.94.2-r0 2010-06-11T22:59:26Z ChrisKuklewicz regex-compat-0.93.1-r0 2010-06-11T22:58:19Z ChrisKuklewicz regex-base-0.93.2-r0 This package take-over is also tracked at https://github.com/haskell-infra/hackage-trustees/issues/238

5 4

Proposal: add `on` to the Prelude
by David Feuer 16 Sep '19

16 Sep '19

Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function whose implementation is barely longer than the import. And it's a really good function too! Can we please add it to the Prelude? on :: (b -> b -> c) -> (a -> b) -> a -> a -> c (.*.) `on` f = \x y -> f x .*. f y

18 37

Proposal: Add cons function to Data.List module
by Helmut Schmidt 16 Sep '19

16 Sep '19

For more or less the same reasons that "singleton" was considered worth being added to Data.List I propose to add "cons" to Data.List as well. ## Motivation Sometimes it is convenient to have a function to prepend an element to a list in pointless style code. But of the existing ways none of them are as clear as a separate monomorphic function. - "( : )" is subjectively ugly - "(\x xs -> x : xs)" is syntactically noisy Purescript also has a "Cons" function so why can't we have one too? We already have "Data.List.uncons" and so for symmetry one would also expect to find "Data.List.cons". Many sequence like APIs have a "cons" function such as https://www.stackage.org/haddock/nightly-2019-09-11/vector-0.12.0.3/Data-Ve… I can't be the only that wants this function, right? ## Proposal Add cons :: x -> [x] -> [x] cons = (:) to Data.List

7 7

About WrappedMonoids deprecation
by Georgi Lyubenov 16 Sep '19

16 Sep '19

Hello! Sorry if this is not the right place to ask! As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated <https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Semigroup.html#…> . I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread <https://twitter.com/googleson78/status/1172944490597945344>. Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? Cheers, Georgi

4 3

Re: About WrappedMonoids deprecation
by John Villarreal 15 Sep '19

15 Sep '19

Hi, I wasn't aware of that. I don't understand your a) and b) points though. Semigroup is a superclass of Monoid, so doesn't that already express the necessity that everyting which is a Monoid is also a Semigroup? And there's also no boilerplate manual aliasing in my version of your example, or is it? On Saturday, 14 September 2019, 20:52:56 UTC, Georgi Lyubenov <godzbanebane(a)gmail.com> wrote: Haskell allows you to "recursively" define instances of superclasses with functions defined in subclass instances. This is fine: ``` data List a ... instance Monoid (List a) ... -- give a definition for mappend here instance Semigroup (List a) where (<>) = mappend ``` You can do a similar thing by first defining Monad for a type and then giving implementations for Functor and Applicative by using Control.Monad.liftM and Control.Monad.ap The benefit is that you can a) directly express the necessity that everything which is a Monoid is also a Semigroup already b) not write the boilerplate of manually aliasing (<>) to mappend (and in general for bigger chains of typeclasses/more typeclass functions this becomes more convenient) On Sat, Sep 14, 2019 at 11:36 PM John Villarreal <j0villarreal(a)yahoo.com> wrote: Hello Georgi, I'm confused about WrappedMonoid. How can something have a Monoid instance already without having a Semigroup instance in the first place? But also what is the benefit of WrappedMonoid over the standard way of defining Semigroups and Monoids for your example data List a = Nil | Cons a (List a) instance Semigroup (List a) where Nil <> ys = ys Cons x xs <> ys = Cons x (xs <> ys) instance Monoid (List a) where mempty = Nil ? Cheers,John On Saturday, 14 September 2019, 19:18:01 UTC, Georgi Lyubenov <godzbanebane(a)gmail.com> wrote: Hello! Sorry if this is not the right place to ask! As of right now (14.09.2019) Data.Semigroup.WrappedMonoid is slated to be deprecated. I believe that this newtype is actually useful in tandem with DerivingVia, as it allows you to derive the Semigroup instance for something that has a Monoid instance already, as discussed in this twitter thread. Would it be possible to *not* deprecate it in the future, and instead keep it around for exactly this purpose? Cheers, Georgi_______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0