- Libraries - Haskell.org

Reviving strict-concurrency
by Yitzchak Gale 29 Aug '17

29 Aug '17

The base library does not provide strict variants for the basic concurrency primitives. Instead, the haddocks for Control.Concurrent.MVar recommend using Don Stewarts's strict-concurrency library: https://hackage.haskell.org/package/strict-concurrency But that library has not been buildable for years. The homepage seems no longer accessible, and there is no source repository link. I created a github repo from the tarball for version 0.2.4.1 (the latest, from 2010), and then made the minor tweaks needed to get it build with modern GHC. The library provides no tests, so I have no idea if what I did still provides the advertised guarantees or even actually works. My repo is here: https://github.com/ygale/strict-concurrency Is the library still as critical as it used to be? Perhaps not in this age of async and STM, but to me it still makes sense to offer strict versions of these primitives. If so, then perhaps this small and simple library should be taken under the wing of libraries as maintainer. In any case, could someone please at least apply my patch and upload to hackage, so that it will be buildable again? I became aware of this because I was hoping to use vacuum for a complex debugging task, but vacuum also hasn't been buildable for several years due to its dependence on strict-concurrency. Whether vacuum will actually work after several years of neglect is a separate question. Thanks, Yitz

3 3

Does the streaming package need a new/additional maintainer?
by David Feuer 28 Aug '17

28 Aug '17

The streaming package has a couple old pull requests that have not been commented on. My recently reported issues and pull requests have also met with silence. It appears that the maintainer, Michael Thompson, was last active on GitHub and Reddit in April. I emailed him a few days ago, but have not yet received a response. I hope he is just on a short break, but if not, someone should probably take over the package. David

2 2

Skip for ReadP/ReadPrec
by Zemyla 21 Aug '17

21 Aug '17

It occurs to me that, when it comes to the ReadP/ReadPrec parser combinators in base, that a common use pattern is to use "look", parse the next value and the number of characters taken from the string, and then use "get" repeatedly to skip ahead that number. Something along the lines of: readSkip :: (String -> Maybe (a, Int)) -> ReadP a readSkip prs = do s <- look case prs s of Nothing -> pfail Just (a, n) -> let go i | i <= 0 = return a go i = get >> go (i - 1) in n `seq` go n It's also the sort of thing that munch, munch1, and skipSpaces do a lot, and as skipSpaces at the very least is common, it should be optimized. My thought was adding a constructor to the internal P type, like so: data P a = ... -- existing cases | Skip {-# UNPACK #-} !Int (P a) And a smart constructor, such as: skipP :: Int -> P a -> P a skipP n p | n `seq` p `seq` False = undefined skipP n p | n <= 0 = p skipP _ Fail = Fail skipP n (Skip m p) = Skip (m + n) p skipP n p = Skip n p Skips would be combined in the (>>=) and (<|>) functions: Skip n p >>= f = skipP n (p >>= f) Skip m p <|> Skip n q = case compare m n of LT -> skipP m (p <|> skipP (n - m) q) EQ -> skipP m (p <|> q) GT -> skipP n (skipP (m - n) p <|> q) Skip m p <|> Get f = Get $ \c -> skipP (m - 1) p <|> f c -- and similarly backwards Skip m p <|> Look f = Look $ \s -> Skip m p <|> f s -- and similarly backwards This would also allow for an optimization in the Look + Get case: Look fl <|> Get fg = Look $ \s -> case s of [] -> fl [] c:_ -> fl s <|> skipP 1 (fg c) The only thing that would be exported would be an actual skip function: skip :: Int -> ReadP () skip n | n `seq` False = undefined skip n = R $ \c -> skipP n $ c () And the Skip constructor can be used instead of the "discard"-like functions in munch, munch1, (<++), and skipSpaces. A "skip" function could also be included in Text.ParserCombinators.ReadPrec, but since that module is imported unqualified more often, it might collide with user-defined functions; even if it isn't exported, it can be emulated with skip :: Int -> ReadPrec () skip n = readP_to_Prec $ const $ ReadP.skip n Incidentally, if the invariant of the list in the Final constructor being non-empty is supposed to be enforced, then shouldn't the constructor for it be something along the lines of: Final (a, String) [(a, String)] ?

1 0

Discussion: Allow custom constraint for elem in Foldable
by David Feuer 28 Jul '17

28 Jul '17

The Foldable class offers the method elem :: Eq a => a -> t a -> Bool Unfortunately, this is really awful for sets, hash maps, etc. See https://stackoverflow.com/questions/45361801/implement-an-olog-n-foldable-e… for an example. We could fix it, kinda: class Foldable t where type ElemConstr t :: * -> Constraint type ElemConstr t = Eq elem :: ElemConstr t a => a -> t a -> Bool default elem :: (ElemConstr t ~ Eq, Eq a) => a -> t a -> Bool One might legitimately complain that such a wild type is ad hoc, but one might counter that complaint by saying that most of Foldable is already ad hoc. David

7 7

Re: Discussion: Allow custom constraint for elem in Foldable
by Carter Schonwald 27 Jul '17

27 Jul '17

i wasnt aware of such guidelines for the libraries list constrained monads/ functors are still an area of study / experimentation, they need experimentation and more community knowledge before they land in base for core type classes On Thu, Jul 27, 2017 at 8:37 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Off-list: Repeating what Eric Mertens said does not contribute to the > discussion. Perhaps you can offer an answer to my follow-up question to him. > > On Jul 27, 2017 8:26 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> agreed. >> >> this needs to be tested out in a user space lib first. >> >> >> On Thu, Jul 27, 2017 at 7:35 PM, Eric Mertens <emertens(a)gmail.com> wrote: >> >>> I would prefer to see designs for something like this explored in a >>> separate package before we worried about changing base’s Foldable class. >>> >>> > On Jul 27, 2017, at 3:45 PM, David Feuer <david.feuer(a)gmail.com> >>> wrote: >>> > >>> > The Foldable class offers the method >>> > >>> > elem :: Eq a => a -> t a -> Bool >>> > >>> > Unfortunately, this is really awful for sets, hash maps, etc. See >>> > https://stackoverflow.com/questions/45361801/implement-an-ol >>> og-n-foldable-elem-for-binary-search-trees-in-haskell#45362110 >>> > for an example. We could fix it, kinda: >>> > >>> > class Foldable t where >>> > type ElemConstr t :: * -> Constraint >>> > type ElemConstr t = Eq >>> > >>> > elem :: ElemConstr t a => a -> t a -> Bool >>> > default elem :: (ElemConstr t ~ Eq, Eq a) => a -> t a -> Bool >>> > >>> > One might legitimately complain that such a wild type is ad hoc, but >>> > one might counter that complaint by saying that most of Foldable is >>> > already ad hoc. >>> > >>> > David >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries(a)haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>

1 0

Data.List.singleton
by Ben Franksen 27 Jul '17

27 Jul '17

...is a function that seems to be missing from base. It is trivial, of course, but still would be nice to have for symmetry with the modules in container. (apologies if this has been discussed before) Cheers Ben

3 2

Exporting ioToST from Control.Monad.ST
by Andrew Martin 20 Jul '17

20 Jul '17

There's a function stToIO that is defined in GHC.IO and exported from Control.Monad.ST. There's another function, ioToST, that's also defined in IO, but it isn't exported from Control.Monad.ST. I propose that it be exported from Control.Monad.ST. -- -Andrew Thaddeus Martin

2 3

Re: Heterogeneous equality into base?
by Ryan Scott 18 Jul '17

18 Jul '17

Sorry for only just discovering this thread now. A lot of this discussion is in fact moot, since (:~~:) already is in base! Specifically, it's landing in Data.Type.Equality [1] in the next version of base (bundled with GHC 8.2). Moreover, it's constructor is named HRefl, so your wish has been granted ;) As for why it's being introduced in base, it ended up being useful for the new Type-indexed Typeable that's also landing in GHC 8.2. In particular, the eqTypeRep function [2] must return heterogeneous equality (:~~:), not homogeneous equality (:~:), since it's possible that you'll compare two TypeReps with different kinds. Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/99adcc8804e91161b35ff1d0e5f718d18fcaa66… [2] http://git.haskell.org/ghc.git/blob/99adcc8804e91161b35ff1d0e5f718d18fcaa66…

9 11

Re: Heterogeneous equality into base?
by Ryan Scott 10 Jul '17

10 Jul '17

I also agree that we should keep HRefl a distinct name, and moreover, we should keep :~: and :~~: as distinct datatypes. I'm also on-board with the idea that we should introduce a separate Data.Type.Equality.Hetero module that reexports :~~: and defines heterogeneous counterparts for sym, trans, etc. from Data.Type.Equality. I don't have a strong opinion on how they should be named (e.g., sym vs. hsym). Ryan S.

5 7

Heterogeneous equality into base?
by Wolfgang Jeltsch 07 Jul '17

07 Jul '17

Hi! The module Data.Type.Equality in the base package contains the type (:~:) for homogeneous equality. However, a type for heterogeneous equality would be very useful as well. I would define such a type as follows: > {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-} > > data (a :: k) :~~: (b :: l) where > > Refl :: a :~~: a Is there already such a type in the base package? If not, does it make sense to file a feature request (or would such a proposal be likely to not being accepted for some reason)? All the best, Wolfgang

6 7