September 2019 - 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

Add NonEmptyMap and NonEmptySet to containers
by V.Liepelt 26 Nov '19

26 Nov '19

Hi John, I saw your thread about non-empty containers today. Why not call them `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? I think most agree that `NonEmpty` is not a great name—I couldn’t summarise it better than Andreas: "NonEmpty what?”. Hence I always do the following: ``` import Data.List.NonEmpty (NonEmpty) import qualified Data.List.NonEmpty as List1 type List1 = NonEmpty ``` In fact I just hoogled for this and noticed that the rebase package seems to do this too. More anecdotal precedent: recently a colleague wrote a datatype isomorphic to `(a, a, [a])` and called it something not quite as ridiculous as `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody involved was happy with that. Vilem

12 12

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

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

13 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