- Libraries - Haskell.org

Add instance Storable Ordering
by Dannyu NDos 08 Oct '19

08 Oct '19

7 8

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

02 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 15 Sep '19

15 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 15 Sep '19

15 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 15 Sep '19

15 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 14 Sep '19

14 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

Incremental Regex Parsing with Fixed Strings
by Andrew Martin 12 Sep '19

12 Sep '19

Greetings, In Dan Piponi's blog post Fast Incremental Regular Expression Matching with Monoids [1], he outlines a way to take advantage of fingertrees to perform increment regex matching. In his article, the regular expression (more accurately, its equivalent DFA) is fixed, and the strings we are matching on are modified incrementally. What I'm interested in is the opposite: What if the regular expression is modified incrementally and the string we are testing is static? Thinking about this, it seems to run into problems immediately. Typically, to evaluate a regular expression, I would convert it to a NFA (and then maybe to a DFA). But there is no way to do incremental graph modification on the resulting graphs. (Or is there?). And even if there were a way, it seems unclear how one would go about exploiting its incremental nature. To provide an example, consider the following regex and sample string: Regex: Lost (dog|cat) loo for home Sample: Lost dog looking for home In the regex, I'm currently in the middle of typing "looking", so it doesn't match the sample string. But large parts of it do. So when I update the regex by typing "k", I'd like to be able to not redo this work. Maybe there's a certain subset of regex that's amenable to this kind of incremental evaluation. Maybe not. If anyone has any additional insights or can point me to any research, I would appreciate it greatly. Thanks. [1] http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html -- -Andrew Thaddeus Martin

5 6

Strict getContents
by Li-yao Xia 12 Sep '19

12 Sep '19

Hello Libraries, In base, the functions which read all contents from a handle or file into one String currently all do lazy IO: readFile, getContents, hGetContents. https://hackage.haskell.org/package/base-4.12.0.0/docs/System-IO.html#v:hGe… The easiest way to get a strict alternative seems to be to explicitly force the list, for example using ```length contents `seq` pure ()```, but that's far from an obvious solution. Is there a better way? If not, I propose to add readFile', getContents', hGetContents', which don't do lazy IO. It regularly creates confusion among beginners, and it's easy to assume that lazy IO is benign if that's the only way to do certain operations, when it's arguably the wrong way to read files to begin with. Cheers, Li-yao

6 7

Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics
by Alexis King 11 Sep '19

11 Sep '19

Hi all, In recent years, the DefaultSignatures extension has seen popular use as a mechanism for providing derived typeclass instances via GHC.Generics. Although undeniably useful, I have always felt it is somewhat ugly: it is mutually exclusive with other, non-Generic default method implementations, and it can only be used for one Generic deriving mechanism, so implementations must choose between GHC.Generics and Data.Data. Fortunately, with the advent of DerivingVia, there is a better way: simply attach generic instances to a separate newtype, defined like newtype Generically a = Generically { unGenerically :: a } instance Generic a => C (Generically a) where ... then derive instances using DerivingVia as follows: data Foo = Bar X | Baz Y Z deriving C via Generically Foo The `Generically` name already exists for this purpose in the `generic-data` package, making it a good candidate name for a newtype in GHC.Generics (`generic-data` could simply re-export the type with suitably recent versions of `base`). An alternate name would be the more traditional `WrappedGeneric`. I don’t have much of a preference either way, but I do think the `Generically` name is cute, especially when used with DerivingVia. I believe this type should be in `base` because it is (1) clearly generally useful in the same way that similar newtypes in `base` like `WrappedMonad` are (and probably even more so), (2) extremely lightweight in terms of additional API complexity (it’s just a newtype), (3) isn’t worth depending on a separate package for, encouraging a proliferation of (possibly name-conflicting) newtypes in individual packages if it isn’t in `base`, and (4) is an opportunity to add instances based on `Generic` for classes already in `base`. Overall, it’s something that would feel right at home in GHC.Generics to me. As a final note, whichever name people prefer, it would of course make sense to provide an analogous `Generically1` or `WrappedGeneric1` type for `Generic1` (as `generic-data` does as well). Alexis

7 17