August 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

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

Fwd: Proposal: Add singleton function to Data.List module
by Sven Panne 09 Sep '19

09 Sep '19

Am Mi., 21. Aug. 2019 um 12:22 Uhr schrieb Nathan Bouscal < nbouscal(a)gmail.com>: > I would strongly encourage anyone inclined to say things like “there's no benefit > in having the function” to consider reframing the sentiment as “I wouldn’t > benefit from having the function, and don’t understand the benefit others > will gain.” Once you’ve done that reframe, you can notice that there’s a > lack of understanding toward which the appropriate emotional stance is > curiosity, not dismissiveness. A lot of people have clearly expressed in > this thread that they would benefit from this function, and when you assert > as fact that such benefit does not exist, you’re implicitly dismissing and > devaluing their experience. [...] > There is also another side of the coin: A lot of people have clearly expressed counterarguments, so *their* experience has been equally "dismissed" or "devalued". Reframing the discussion shouldn't be biased, otherwise it's just a cheap trick to make one side of the discussion more valuable/stronger. Furthermore, a technical discussion doesn't need to be an excercise in nonviolent communication, as long as people don't start insulting each other. I think the main problem of this discussion (and other similar threads on this list) is that there is no consensus about how to design an API. IMHO, piling up little helpers just because they came up in a few places is a recipe for horrible, bloated APIs. The questions one should ask are "Does it generalize things?", "Does it make my API more powerful?" (i.e. can I do things I couldn't do before), "Does it remove common pitfalls?" etc. But this is just my personal view, obviously others seem to disagree.... :-/

10 13

long double
by Dannyu NDos 30 Aug '19

30 Aug '19

Could we implement IEEE quadruple-precision (binary128) format?

5 6

Faster complex number multiplication
by Dannyu NDos 28 Aug '19

28 Aug '19

It is possible to have 3 multiplications rather than 4: https://en.m.wikipedia.org/wiki/Multiplication_algorithm#Complex_multiplica…

3 4

Generalize runSTArray and runSTUArray
by Zemyla 26 Aug '19

26 Aug '19

The "runSTArray" and "runSTUArray" functions allow efficiently working with Arrays in the ST monad before turning them immutable; however, they don't allow any way to return supplemental or alternative information with the array. There are many times when I've wanted to get an (Array i e, w) or a Maybe (UArray i e), but I couldn't, and had to use the far-more-inefficient freezeArray and hope it inlined properly. What I want are functions that generalize the return types given: runSTArrayTrav :: Traversable t => (forall s. ST s (t (STArray s i e))) -> t (Array i e) runSTArrayTrav m = runST $ m >>= traverse unsafeFreezeSTArray runSTUArrayTrav :: Traversable t => (forall s. ST s (t (STUArray s i e))) -> t (UArray i e) runSTUArrayTrav m = runST $ m >>= traverse unsafeFreezeSTUArray And then an even more generalized version, which takes a sort of Lens-like iterator, and allows returning multiple arrays of different kinds, types, and indices: runSTArrayWith :: (forall f s. Applicative f => (forall i e. STArray s i e -> f (Array i e)) -> (forall i e. STUArray s i e -> f (UArray i e)) -> u s -> f v) -> (forall s. ST s (u s)) -> v runSTArrayWith tr m = runST $ m >>= tr unsafeFreezeSTArray unsafeFreezeSTUArray The advantage of the runSTArrayTrav/runSTUArrayTrav functions, if they're subsets of the runSTArrayWith function, is that it works with standard things like (,) and Either, and doesn't require wrapping it in a newtype so that the s is at the end. The names of the functions are up for debate, and I know there will be one, because naming things is one of the two hard problems in computer science, along with cache invalidation and off-by-one errors.

4 6

Proposal: Add singleton function to Data.List module
by Taylor Fausak 22 Aug '19

22 Aug '19

I originally made this suggestion on GitLab, but I was told to make it here instead. https://gitlab.haskell.org/ghc/ghc/issues/17042 --- # Add list singleton function ## Motivation Sometimes it is convenient to have a function to wrap an element in a list. There are many ways to do this already, but none of them are as clear as a separate monomorphic function. - `pure`: Polymorphic, works for any `Functor`. - `pure @[]`: Noisy, requires `-XTypeApplications`. - `(: [])`: Subjectively ugly. - `(\x -> [x])`: Syntactically noisy. This Twitter thread includes some additional commentary: https://twitter.com/taylorfausak/status/1159264862247280640 ## Proposal I would like to add a `singleton` function to `Data.List` that mirrors the `singleton` function for other containers: https://www.stackage.org/lts-14.0/hoogle?q=singleton ``` hs singleton :: a -> [a] singleton x = [x] ``` Other Haskell-like languages include this function: - PureScript: https://pursuit.purescript.org/packages/purescript-lists/5.4.0/docs/Data.Li… - Elm: https://package.elm-lang.org/packages/elm/core/latest/List#singleton

37 62

Re: Proposal: Add singleton function to Data.List module
by David Duke 18 Aug '19

18 Aug '19

Stepping to one side of the discussion could I just point out that, notation is not just about the form of the final program. One of the claimed strengths and appeals of FP is the opportunity for program transformation via a useful repertoire of algebraic law, cf the work on Squiggol, and the numerous functional pearls by folk including Richard Bird et.al.. This work befits from having concisely-expressed rules that open the road to manipulation - long-winded identifiers suitable for large libraries are not necessarily ideal for algebraic manipulation. Ye you could treat the two as separate entities, But a pleasant feature of Haskell is the ability to work with the notation both for developmemt and final program. Going back to the original proposal, I'm not bothered, I would probably just ignore a singleton library. However I'm -1 on philosophical grounds. I'm used to teaching FP to undergrads and half the battle is encouraging people to think functionally, to make use of the underlying mathematics and computational model rather than transliterate <insert your favourite 'bete noir'> into Haskell. That means thinking of building programs from functional fragments combined by suitable glue, and appreciating that data constructors can be used as functions Yes it takes beginner's time to recognise some of the patterns, and (:[] is just one such example(when the light dawns, the transformation is rewarding. I've lost count of the number of jaws I've had to pick off the floor :) So I don't want to make a mountain out of a molehill. If it will really improve programmers' lives then okay, So far I' not convinced, and but in fretting over final code can we please not lose sight of the 'bigger picture' and challenges.. -- David Duke E:duke.j.david@gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke

1 0