June 2020 - Libraries

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

Re: Future of lucid
by Simon Jakobi 10 Jun '20

10 Jun '20

That's good to hear, Chris! Can I suggest to include a version of this explanation in the README? Maybe you could also suggest that people post their questions on SO using the haskell-lucid tag: https://stackoverflow.com/questions/tagged/haskell-lucid Cheers! Simon Am Mi., 10. Juni 2020 um 15:23 Uhr schrieb chris done <haskell-cafe(a)chrisdone.com>: > > 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 > Dhall documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > >

1 0

Discussion: lookups in maps
by David Feuer 10 Jun '20

10 Jun '20

Discussion has gotten going again about harmonizing between the names findWithDefault and lookupDefault in containers and unordered-containers: findWithDefault :: Ord k => a -> k -> Map k a -> a lookupDefault :: (Eq k, Hashable k) => a -> k -> HashMap k a -> a I've been fairly unenthusiastic about adding extra names for this function in one package or the other, in large part because I don't like the function. I'd much rather have something in the spirit of `either`, `maybe`, `bool`, etc.: lurkup :: Ord k => r -> (a -> r) -> k -> Map k a -> r lurkup r f k = maybe r f . lookup k lookup k = lurkup Nothing Just k Unfortunately, I haven't been able to come up with a decent name for this function. Can anyone help?

7 6

Question about the portability of containers
by Fumiaki Kinoshita 09 Jun '20

09 Jun '20

I noticed that there are massive amount of CPP pragmas to switch code between GHC and non-GHC (e.g. https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/Int…) and they are a burden for maintainers. Moreover, the non-GHC part of the codebase is untested due to the lack of viable alternative compilers ( https://github.com/haskell/containers/pull/728#discussion_r436318206) Therefore I propose to revisit the policy for portability of core libraries. Portability is not a bad thing, but few people use other compilers these days. The drag is only likely to increase because there's no plan (AFAIK) for a new Haskell standard.

5 6

Future of lucid
by Simon Jakobi 09 Jun '20

09 Jun '20

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 Dhall documentation generator that is being developed as a part of this year's GSoC. Thanks! Simon

1 0

Type signature of readIntP seems redundant?
by Dannyu NDos 08 Jun '20

08 Jun '20

Current type signature of readIntP is: readIntP :: Num a => a -> (Char -> Bool) -> (Char -> Int) -> ReadP a This seems kinda redundant. It inputs two functions, one checking whether a character is valid digit, and the other assigning an integer to the digit. Shouldn't we merge them together to one function? Like this: import Control.Monad import Data.Foldable import Data.Maybe import Text.ParserCombinators.ReadP readIntP :: Num a => a -> (Char -> Maybe Int) -> ReadP a readIntP base valDigit = do maybeNs <- manyTill (fmap (fmap fromIntegral . valDigit) get) $ do str <- fmap (fmap valDigit) look case str of [] -> return () (Nothing:_) -> return () _ -> pfail let n = foldl' (\l r -> case l of Nothing -> r Just l1 -> fmap (base * l1 +) r ) Nothing maybeNs guard (isJust n) return (fromJust n)

3 2

New maintainers of Core Libraries
by chessai 08 Jun '20

08 Jun '20

All, `vector`, `random`, and `primitive` have new maintainers. vector (https://github.com/haskell/vector) Alexey Kuleshevich ( https://github.com/lehins) Alexey Khudyakov (https://github.com/Shimuuar) , Andrew Lelechenko (https://github.com/Bodigrim) random (https://github.com/haskell/random) Alexey Kuleshevich ( https://github.com/lehins) Dominic Steinitz ( https://github.com/idontgetoutmuch) Leonhard Markert ( https://github.com/curiousleo) Alexey Khudyakov ( https://github.com/Shimuuar) , Andrew Lelechenko ( https://github.com/Bodigrim) primitive (https://github.com/haskell/primitive) Andrew Martin ( https://github.com/andrewthad) David Feuer (https://github.com/treeowl) chessai (https://github.com/chessai) They are all trustworthy, knowledgeable, passionate, and looking forward to serving the Haskell community! Furthermore, throughput on contributions to these libraries should increase with all the new maintainers. Reach out to me (chessai1996(a)gmail.com) if you have any questions. Thanks!

2 3