- Libraries - Haskell.org

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 28 Jul '17

28 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

File operations in base and fork+exec
by Merijn Verstraaten 23 Jun '17

23 Jun '17

Hi! So I realise proposing backwards incompatible changes to base is tilting at windmills, but I just noticed that most (all?) file operations in base don't open files with O_CLOEXEC, which basically means that every open Handle/file descriptor gets leaked to every single subprocess you fork+exec from Haskell. This seems highly undesirable. For POSIX there appears to be an operation in base that disables this, but it doesn't seem to easily exported. I would like to propose that all operations in base open files with O_CLOEXEC by default and exposing an easy method to mark specific file descriptors to be preserved across exec (This can be achieved by using fcntl to remove the CLOEXEC bit from a specific fd). I'm not sure to what extent Windows behaviour is similar to POSIX, but in principle it should behave the same, I think. Cheers, Merijn

7 6