- Libraries - Haskell.org

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

Generalize IsString
by Dannyu NDos 07 Jun '20

07 Jun '20

As we already have IsList, shouldn't we just do this? class (IsList l, Item l ~ Char) => IsString l instance (a ~ Char) => IsString [a] instance (a ~ Char) => IsString (NonEmpty a) instance (a ~ Char) => IsString (ZipList a)

4 4

Sliding windows for streaming
by David Feuer 06 Jun '20

06 Jun '20

I'm looking for a bit of help with a library design choice. The streaming package currently offers a slidingWindow function converting a stream into a stream of fixed-size windows of that stream[1]: slidingWindow :: Monad m => Int -- Window size -> Stream (Of a) m b -> Stream (Of (Seq a)) m b This is based directly on a similar function in conduit. Using a rough translation into the world of lists, we have slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] The awkward case where the stream is shorter than the window is handled by potentially producing a short sequence at the end: slidingWindow 3 "ab" = ["ab"] slidingWindow 3 "" = [""] I recently merged a pull request that adds variations on sliding window maxima and minima using what's apparently a "folklore" algorithm. For example slidingWindowMax 3 "abcbab" = "abcccb" This is basically like slidingWindowMax k = map maximum . slidingWindow k except that an empty stream doesn't yield anything, to avoid undefined values. The big advantage of these specialized functions is that rather than having to take a maximum over a sequence of length `k` at each step, they only do a constant (amortized) amount of work at each step. Nice! But not very general. Suppose we want to take a moving average of some sort, like an arithmetic mean, geometric mean, harmonic mean, or median? That thought leads quite naturally to a data structure: a queue holding elements of some arbitrary *semigroup* that efficiently keeps track of the sum of all the elements in the queue[2]. While the choice of *data structure* is moderately obvious, the choice of *sliding window function* is less so. The tricky bit is, again, what happens when the stream is too short for the window. If you work in the Sum semigroup and divide the results by the window size to get a moving average, then a too-short stream will give a (single) result that's completely wrong! Oof. What would be the most useful way to deal with this? The streams in `streaming` give us the option of producing a distinguished "return" value that comes after all the yields. Would it make sense to *return* the incomplete sum, and the number of elements that went into it, instead of *yielding* it into the result stream? That seems flexible, but maybe a tad annoying. What do y'all think? [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelud… [2] See the AnnotatedQueue in https://github.com/haskell-streaming/streaming/pull/99/files which basically modifies Okasaki's implicit queues using some of the basic ideas that appear in Hinze-Paterson 2–3 trees.

2 2

Re: [core libraries] Adding Backwards to base, re-export from Control.Applicative
by Baldur Blöndal 06 Jun '20

06 Jun '20

I'll CC Haskell Libraries þri., 12. nóv. 2019 kl. 22:14 skrifaði Ryan Scott <ryan.gl.scott(a)gmail.com>: > This discussion definitely belongs on the mailing list, yes. > > Ryan > > On Tue, Nov 12, 2019 at 11:59 AM chessai . <chessai1996(a)gmail.com> wrote: > >> I support this. +1 >> >> Should we copy in the libraries mailing list? >> >> On Tue, Nov 12, 2019, 5:56 AM Baldur Blöndal <baldurpet(a)gmail.com> wrote: >> >>> Is it time to move Control.Applicative.Backwards module from >>> transformers to base, and maybe re-export it from Control.Applicative. >>> >>> It's an interesting, important, simple property of Applicative that they >>> can be run backwards. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-core-libraries" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3…> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg… >> <https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg…> >> . >> >

8 7

Ann: let’s create better norms for ensuring all important libraries have several active maintainers
by Carter Schonwald 05 Jun '20

05 Jun '20

I’m very happy that we now agree to have several active comaintainers for all core/systematically . (though the specifics of how it was done this week i view as anthetical to what our community represents and values.) There’s ways of doing that can be done in a good faith way. I’m definitely not perfect. I also have spent much of the past five years trying to learn to manage my somewhat aggressive and personal flavor of generalized anxiety disorder (certain flavors of anxiety or depression in men present as aggressive behavior ). Some of my approaches on tickets that people find frustrating are my attempt to avoid getting fixated on getting into Interpersonal conflicts rather than trying to shut those voices down. Also I find it hard to have those dialogues in that communication format. For asynchronous conversations in different time zones I fully welcome discord or what’s app or signal or freenode irc. Conversations with emotional dimensions are challenging in email. Let alone with issue trackers! In the past month I was working with Simon Jakobi and Andrew lelechenko as a sort of pilot for a new Haskell action team (HAT) with them as the initial leadership for 2020, to have some folks we all recognize to have excellent taste and engineering to help support and triage all maintainers and efforts. We spent a bit of time helping out on bytestring and I think that was a success. and I hoping they and other members of HAT can make a big difference across all the important libraries we have. I look forward to support HAT via my role as CLC. More broadly, I was also privately in discussion with some folks before this week's tornado about how to move to make it the norm for all core / important libraries have 3-5 variously active and diversely different comaintainers. What happened this week is not how id have liked it to be rolled out, and I’m in the best of head spaces at the moment, but I think it is VERY good that we collectively agree there should be a norm of actively making sure there are several diverse co maintainers for every such library. how it was handled this week is not how it should have been handled, i pray that no one ever views this as grounds for similar treatment of people inour community who have been trying to be in their own way, good caretakers of important community resources In terms of what i like and appreciate about this community, I would like to challenge us all to think about how we can turn frustration into concrete and positively actionable feedback that supports each other in a good faith positive way. I feel that we all failed colectively, and thats fine, but i hope we can learn to engage in this differently. perhaps most importantly, i think its GENUINELY important to strive to support and enable every project to have a genuinely diverse maintainer set for all of our important libraries, both in terms of age, creed and whatever. Haskell has failed to do a good job of that in the past, and i challenge us all to work to address that starting with our core going forward On Fri, Jun 5, 2020 at 8:32 AM Mathieu Boespflug <m(a)tweag.io> wrote: > Zemyla, > > I would expect more charitable reception of anything said by anyone, but > especially when the original author stated clearly in the very same message > that they are not a native English speaker. And even if the words are to be > taken on face value, do note that no one has called anyone a tyrant. > Calling out specific behaviour (that predates the current pandemic) as > "tyrannous" (or "tyrannical") and naming someone a tyrant is simply not the > same thing. > > > On Fri, Jun 05, 2020 at 13:06:20, Zemyla <zemyla(a)gmail.com> wrote: > >> So you're saying that the fact that there's basically a civil war and >> pandemic going on is no excuse to respond to e-mails. And you're calling >> his behavior "tyrannous" when there are literal tyrants shooting tear gas >> at civilians. >> >> I gotta admit, this makes me disinclined to believe you're acting in good >> faith. Sometimes shit happens to good people, and someone who can't show a >> little compassion in these (pardon the cliche) unprecedented times is not >> someone I want anywhere involved in package management. >> >>

4 6