- Libraries - Haskell.org

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

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

Re: Proposal: Add singleton function to Data.List module
by Ryan Scott 08 Sep '19

08 Sep '19

> Meanwhile, Ryan GL Scott managed to > accumulate enough data to show that breakage this one combinator would > introduce was pretty minor after all, so we're going to go ahead with > adding singleton before the rest of this happens. In case you're curious what this data looks like: I compiled GHC 8.6.5, but with the singleton function added to Data.List, and built a decently large variety of libraries from Hackage to see what would break. When I was done with this informal experiment, my ~/.cabal/store directory for this version of GHC had 523 entries, which provides a loose upper bound on the number of libraries that successfully built (there are some duplicate entries). You can view these store entries at [1]. Of these ~500 or so libraries, there were a grant total of three that did not build out of the box: * blank-canvas-0.7 * ghc-lib-parser-8.8.0.20190723 * pandoc-2.7.3 Of course, this experiment is not exhaustive—there are many other libraries out there, and there is also lots of code that is not on Hackage. Nevertheless, the overall percentage of libraries that broke was surprisingly small, and certainly much smaller than my initial estimate. Ryan S. ---- [1] https://gitlab.haskell.org/snippets/1474

1 0

optional definition
by Dannyu NDos 06 Sep '19

06 Sep '19

The current 'one or none' definition breaks the order of elements. It is more Ord-friendly to define it as 'none or one'.

4 4

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