July 2019 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 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

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

Is there a function \x -> (x, x) in standard libraries?
by Ignat Insarov 30 Jul '19

30 Jul '19

Hello. I wonder if there is a function like \x -> (x, x) in the standard libraries. I looked up in Hoogle. It gave me links: 1. https://hackage.haskell.org/package/utility-ht/docs/Data-Tuple-HT.html#v:do… 2. https://hackage.haskell.org/package/extra/docs/Data-Tuple-Extra.html#v:dupe 3. https://hackage.haskell.org/package/relude/docs/Relude-Extra-Tuple.html#v:d… None of these is to the standard library. I wonder if there is an intentional omission for some important reason? If not, I think this function should be added to Data.Tuple. I know some of the persons that make decisions here like Category theory, so I point out this function is mentioned in Categories for the Working Mathematician, as δ, the diagonal function, on page 3 (second edition), although set with angular brackets. Have a great day.

16 19

Re: Proposal: Make Semigroup and Monoid instances for Data.Functor.Compose
by Ryan Scott 26 Jul '19

26 Jul '19

Hi, You may find the discussion at https://mail.haskell.org/pipermail/libraries/2018-February/028571.html interesting. The summarized version of that post is that Data.Functor.Compose was originally brought over from the transformers library, which adheres to a very Haskell98 mindset in its design. In particular, the maintainer of transformers would likely not have added the Semigroup or Monoid instances you propose, since they require the FlexibleContexts language extension. This explains why there exists an `instance (Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a)` and not an `instance Eq (f (g a)) => Eq (Compose f g a)`, among other things. Of course, Data.Functor.Compose now lives in the base library, not transformers, so we need not prescribe to the same design philosophy. I don't feel too strongly about the issue, so if other people feel like adding Semigroup/Monoid instances that require FlexibleContexts is a good idea, I could get on board with that. What do others think? Ryan S.

4 3

Proposal: Make Semigroup and Monoid instances for Data.Functor.Compose
by Keith 25 Jul '19

25 Jul '19

With the Monoid 'First' and 'Last' newtypes going away, it would be nice to have equivalent Functor and Applicative instances. This works if Compose uses its components' instances: instance Semigroup (m (n a)) ⇒ Semigroup (Compose m n a) where Compose mnx <> Compose mny = Compose (mnx <> mny) instance Monoid (m (n a)) ⇒ Monoid (Compose m n a) where mempty = Compose mempty –Keith -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Re: Proposal: composition util for Maps
by Johannes Waldmann 23 Jul '19

23 Jul '19

+0.9 we can have it > composition :: Ord b => Map b c -> Map a b -> Map a c > composition bc ab = flip mapMaybe ab $ flip lookup bc > Which has O(|ab| * log |bc|) performance. The given implementation traverses all of ab even if bc is empty. We could detect this. But for |bc| = 1, there is no work-around? So, O(|ab| * max(1, log |bc|)) ? I think this could only be improved if we had a representation of the inverse of ab as well. I don't think it should be computed on-the-fly, as in https://github.com/haskell/containers/issues/647#issuecomment-504798611 This would better be handled in a proper library for relations ( https://hackage.haskell.org/package/relation has this data type, but does not have composition?) bike-shedding the name and type: * composition vs. compose: the library usually favours the noun: intersection (not intersect), difference (not subtract) * order of arguments: mathematically speaking, it is of course very wrong, but it's consistent with the wrongness of (.) ... - J.W.

3 2

ANNOUNCE: lens-family 2.0.0 anniversary edition!
by roconnor＠theorem.ca 20 Jul '19

20 Jul '19

In celebration of the 10th anniversary of Twan van Laarhoven's seminal blog post ``CPS based functional references''[1], I am releasing version 2.0 of lens-family[2] and lens-family-core[3] packages. This new release continues to explore the design of Van Laarhoven style optics with new support for adapters, grates, grids[4], and prisms. To bring support to these new optics necessarily means moving a little further away from syntactic compatibility with Kmett's lens library. In particular, lens-family's 'under' is unrelated to Kmett's lens library's 'under' combinator. Nonetheless the 'under' combinator plays a crucial role in lens-family as a dual to the 'over' combinator and this naming is hard to resist despite the conflict. This new version comes with some minor incompatibilities with the version 1.2 library that may require user updates. See <https://hackage.haskell.org/package/lens-family-2.0.0/changelog>. [1]<https://www.twanvl.nl/blog/haskell/cps-functional-references> [2]<https://hackage.haskell.org/package/lens-family-2.0.0> [3]<https://hackage.haskell.org/package/lens-family-core-2.0.0> [4]A grid is an optic that is both a grate and a traversal. -- Russell O'Connor <http://r6.ca/>

4 5

Taking over `rungekutta`
by Marco Zocca 16 Jul '19

16 Jul '19

Hi all, I'd like to take over maintainership of this library https://hackage.haskell.org/package/rungekutta Its latest upload was in 2009 and it doesn't have a listed version control repository. I think it's safe to assume it's abandoned. The listed author email is unreachable and I cannot find an alternative email to contact the author. Thank you, Marco

1 0

Cayenne Source Code
by Andrew Martin 09 Jul '19

09 Jul '19

I just read through Lennart's paper on Cayenne, which was written in Haskell. It would be informative for me to look at the source code for a simple dependently typed language like this. (The paper claims the typechecker is only around 5000 LoC.) However, I cannot find the source code anywhere. Has it been devoured by the cruel jaws of the ephemeral web, or does someone out there still have a copy of it? -- -Andrew Thaddeus Martin

3 3