- Libraries - Haskell.org

Random 1.2 Released
by dominic＠steinitz.org 23 Jun '20

23 Jun '20

After a lot of hard work by Alexey Kuleshevich, Leonhard Markert and Dominic Steinitz with help from Aleksey Khudyakov, I am happy to announce version 1.2 of random has finally landed on hackage. * Much, much faster. * Higher quality default generator. * Addition of a monadic interface to support e.g. mwc-random. See https://github.com/haskell/random/blob/master/CHANGELOG.md for more details. There are a few libraries on hackage that do not compile with the latest version and we are providing PRs to fix those. Let us know if we forgot your favourite package. I'd also like to thank the reviewers especially Andrew Lelechenko and @chessai for taking the time to read through the code thoroughly and provide great feedback. Happy Hacking Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch

1 0

Hackage builds failing due to "no space left on device"
by chessai 22 Jun '20

22 Jun '20

Noticed that esqueleto is not building with the following error: /home/builder/hackage-server/build-cache/tmp-install/haddocks/aeson-1.5.2.0-docs/.copyFile2241-42.tmp: copyFile: resource exhausted (No space left on device) cabal: Leaving directory '/tmp/cabal-tmp-20169/aeson-1.5.2.0' cabal: Error: some packages failed to install: aeson-1.5.2.0-8m7uP0LdEdZJovFbkbnljA failed during the final install step. The exception was: ExitFailure 1 conduit-1.3.2-ByhlA7RsvOCCAVlxG8dMJB depends on conduit-1.3.2 which failed to install. conduit-extra-1.3.5-u7qkGOsMDsAnghfNEDjDE depends on conduit-extra-1.3.5 which failed to install. esqueleto-3.3.3.2-IXlW3QxcWcv1TdnLct1H3o depends on esqueleto-3.3.3.2 which failed to install. monad-logger-0.3.32-5FoF5JZYOM2GJkmQhYs1Qk depends on monad-logger-0.3.32 which failed to install. mono-traversable-1.0.15.1-G4IRQAjn5o89QjeJsBIgGz failed during the final install step. The exception was: ExitFailure 1 persistent-2.10.5.2-9pMXVg6QyyTJGyUOWsNLzx depends on persistent-2.10.5.2 which failed to install. (See full build log here: https://hackage.haskell.org/package/esqueleto-3.3.3.2/reports/3) Is anyone else experiencing this?

2 2

generic implementation of Bits.toIntegralSized
by Henning Thielemann 22 Jun '20

22 Jun '20

Documentation of toIntegralSized gives following generic implementation: toIntegral :: (Integral a, Integral b) => a -> Maybe b toIntegral x | toInteger x == y = Just (fromInteger y) | otherwise = Nothing where y = toInteger x I expect that (toInteger x == toInteger x) is always true because of referential transparency, right? I assume the intent was to compare the Integer representations of the parameter and the result. Maybe it should be this way: toIntegral :: (Integral a, Integral b) => a -> Maybe b toIntegral x | toInteger x == toInteger y = Just y | otherwise = Nothing where y = fromInteger $ toInteger x

1 0

Confusion over bitSize, bitSizeMaybe, and finiteBitSize
by chessai 22 Jun '20

22 Jun '20

The documentation for these functions in Data.Bits say that these functions do not evaluate their arguments. This wording is a bit strange to me, since it seems that does not exactly mean that any such implementation _must not_ evaluate its argument. This may be an issue when dealing with types whose inhabitants have finite but not necessarily fixed sizes. For example, there is a valid Bits instance for strict ByteString, which is finite but not fixed-size. My question is, should the wording be changed to be a bit clearer? Or should this restriction exist in the first place?

2 1

Symmetric difference for Set and IntSet
by Andrew Lelechenko 18 Jun '20

18 Jun '20

Hi all, I propose to add a new combining function to `Data.Set` and `Data.IntSet` with the following semantics (but better implementation): symmetricDifference :: Set a -> Set a -> Set a symmetricDifference x y = (x \\ y) <> (y \\ x) The context is that Federico (CC'ed) is working on a GSoC project about faster factorisation algorithms in `arithmoi` (http://hackage.haskell.org/package/arithmoi) and the symmetric difference is a basic building block for sparse linear algebra over GF(2) field. Best regards, Andrew

3 2

Should primMonad class live in base or mtl?
by Carter Schonwald 16 Jun '20

16 Jun '20

This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable Argument in favor of base : there’s absolutely code in base, and packages like array, which would benefit from PrimMonad. Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. ) Argument against base: Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that? Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly. Argument against mtl : aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base. Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base

4 4

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

Re: [Haskell-cafe] Future of lucid
by Carter Schonwald 10 Jun '20

10 Jun '20

Absolutely, but is it viable to ask every maintainer to juggle that discussion about community management fused with technical direction? Maybe? Maybe not. So many things are social constructs fused with how technological systems interact with them! On Wed, Jun 10, 2020 at 1:15 PM Tom Ellis < tom-lists-haskell-cafe-2017(a)jaguarpaw.co.uk> wrote: > There is perhaps a happy medium here, whereby interested parties start > a "friends-of-lucid" repository. Unlimited amounts of discussion > could take place there, and information and PRs could be forwarded > upstream as necessary, in a way that is respectful of the upstream > maintainer. > > On Wed, Jun 10, 2020 at 05:06:19PM +0100, chris done wrote: > > Unfortunately, GitHub doesn't distinguish between "mailing list > > where chat can occur" and "tasks the devs plan to put time and > > energy into", it's all dumped into one pot. > [...] > > > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > > Would it be possible to leave the issue tracker on but just > > > disable your own email notifications for the repository if you do > > > not plan to maintain it? The two main reasons I suggest this are: > > > > > > * We would like a way to be able to petition Oleg for changes (or > > > whoever is the maintainer at the time) > > > > > * We would like to know if other people share the same problem we > > > do (or vice versa, educate other users of problems we are having > > > and potential workarounds) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

Re: [Haskell-cafe] Future of lucid
by Carter Schonwald 10 Jun '20

10 Jun '20

Hey Chris, I definitely feel the same way about GitHub sometimes. I think some of this is often fallout from commercial development processes when a product is evolved using the wrong measurements for evaluating success or failures of change over time. I personally find nontechnical discourse beyond positive exhortations on issue trackers stressful and distracting. (This is an issue with linear threading more broadly when there’s any meaningful emotional dimension). Whatever approach (ethically!) facilitates you sustainably working on projects you have generously made open source / or act as the maintainer for, it is entirely your prerogative to work on them however you like. It’s all neat stuff and keep on having fun! Cheers -Carter On Wed, Jun 10, 2020 at 12:07 PM chris done <haskell-cafe(a)chrisdone.com> wrote: > Hi Gabriel, > > I enabled the issue tracker earlier today for those reasons. > > Unfortunately, GitHub doesn't distinguish between "mailing list where chat > can occur" and "tasks the devs plan to put time and energy into", it's all > dumped into one pot. I consider this a shortcoming of GitHub. It actually > distorts the meaning of "to maintain" from "keeping the software correct > and working" to "responding to and acknowledging any and all commentary by > anyone at any time for any duration, teaching fellow developers about how > to use Git, GitHub, among other mentorship tasks" the temporary or > prolonged neglect of which is deemed to be not putting on a good show, or > in your own words, "not maintaining it". The more I reflect on it, the more > I see why many project maintainers burn out on GitHub. > > I will continue using lucid and patching it to move with the times as > GHC's type system moves along and HTML 5 elements/attributes are added, and > merge pull requests related to these stated goals, for the foreseeable > future, but I plan to do no more than that. If that's not good enough > for Dhall, then there are plenty of other options.[1] > > Cheers, > > Chris > > [1]: > https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing… > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > Would it be possible to leave the issue tracker on but just disable your > own email notifications for the repository if you do not plan to maintain > it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever > is the maintainer at the time) > * We would like to know if other people share the same problem we do (or > vice versa, educate other users of problems we are having and potential > workarounds) > > On Jun 10, 2020, at 6:23 AM, chris done <haskell-cafe(a)chrisdone.com> > wrote: > > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, > nothing substantial has changed in the 6 years since its release. Just > small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage > would cause disruption and I would encourage that to be achieved in a > separate package with a new name. In review, I'm very happy with Lucid's > design and plan to maintain it long-term into the future for as long as > HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker > would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

Re: [Haskell-cafe] Future of lucid
by David Feuer 10 Jun '20

10 Jun '20

Your experience is not mine. Yes, I see support requests and general chatter on GitHub issue trackers I follow, but the volume is miniscule. In my own projects, I tend to close those down pretty quickly unless I think there's a special circumstance. On Wed, Jun 10, 2020, 12:05 PM chris done <haskell-cafe(a)chrisdone.com> wrote: > Hi Gabriel, > > I enabled the issue tracker earlier today for those reasons. > > Unfortunately, GitHub doesn't distinguish between "mailing list where chat > can occur" and "tasks the devs plan to put time and energy into", it's all > dumped into one pot. I consider this a shortcoming of GitHub. It actually > distorts the meaning of "to maintain" from "keeping the software correct > and working" to "responding to and acknowledging any and all commentary by > anyone at any time for any duration, teaching fellow developers about how > to use Git, GitHub, among other mentorship tasks" the temporary or > prolonged neglect of which is deemed to be not putting on a good show, or > in your own words, "not maintaining it". The more I reflect on it, the more > I see why many project maintainers burn out on GitHub. > > I will continue using lucid and patching it to move with the times as > GHC's type system moves along and HTML 5 elements/attributes are added, and > merge pull requests related to these stated goals, for the foreseeable > future, but I plan to do no more than that. If that's not good enough > for Dhall, then there are plenty of other options.[1] > > Cheers, > > Chris > > [1]: > https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing… > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > Would it be possible to leave the issue tracker on but just disable your > own email notifications for the repository if you do not plan to maintain > it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever > is the maintainer at the time) > * We would like to know if other people share the same problem we do (or > vice versa, educate other users of problems we are having and potential > workarounds) > > On Jun 10, 2020, at 6:23 AM, chris done <haskell-cafe(a)chrisdone.com> > wrote: > > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, > nothing substantial has changed in the 6 years since its release. Just > small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage > would cause disruption and I would encourage that to be achieved in a > separate package with a new name. In review, I'm very happy with Lucid's > design and plan to maintain it long-term into the future for as long as > HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker > would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0