- Libraries - Haskell.org

unix: Improve baud rate handling. #135
by Travis Whitaker 14 Jan '20

14 Jan '20

Greetings Haskellers, I am writing to draw your attention to https://github.com/haskell/unix/pull/135. The unix library conditionally supports the common baud rate extensions 57600 and 115200. Modern POSIX systems support a much wider set of extensions, and this PR adds additional extended baud rates that have been available on MacOS and Linux for several years. The same CPP mechanism for conditionally enabling these extensions is used. The PR has been open for a few months and I am interested in moving it forward. Thanks for your time, Travis Whitaker

1 0

WARNING pragmas in `Prelude.undefined` and `Prelude.error`
by Vilem Liepelt 13 Jan '20

13 Jan '20

Has there been any discussion about adding WARNING pragmas to `Prelude.undefined` and `Prelude.error`, as done in some custom preludes? I suppose this hasn't been done yet to avoid breaking existing code which makes "legitimate" use of those helpers?

13 21

haskell/bytestring stalled?
by Fumiaki Kinoshita 13 Jan '20

13 Jan '20

I noticed that issues and PRs on bytestring repository[0] have received no feedback in past 6 months. Does anyone know what's going on? If I can help moving things along, I definitely would like to. [0] https://github.com/haskell/bytestring

6 12

Discussion: forM for Data.Set
by hasufell＠posteo.de 12 Jan '20

12 Jan '20

This was posted a year ago already, but without many comments: https://mail.haskell.org/pipermail/libraries/2019-January/029335.html So after cleaning up the PR a bit, adding tests and benchmarks, let's give it another go. PR is at: https://github.com/haskell/containers/pull/592 New functions are: forM, mapM, for, traverse This follows the other Data.Set exported functions, overwriting Prelude ones like foldr etc, so I think that's exactly what we want. Cheers, Julian Ospald

3 2

Augmented sequence deletion
by David Feuer 28 Dec '19

28 Dec '19

Data.Sequence offers deleteAt :: Int -> Seq a -> Seq a which deletes the element at the given index. Today, I ran into a situation where I wanted to know what was deleted. deleteLookup :: Int -> Seq a -> Maybe (a, Seq a) The closest thing I can find in `containers` is in Data.Map: updateLookupWithKey :: Ord k => (k -> a -> Maybe a) -> k -> Map k a -> (Maybe a,Map k a) Unfortunately, that function is ugly and strange. A better one, whose name I can't guess at the moment: flabbergast :: (a -> (b, Maybe a)) -> Int -> Seq a -> Maybe (b, Seq a) where a Nothing result means the index was out of bounds. There's also a potential flabbergastF :: Functor f => (a -> f (Maybe a)) -> Int -> Seq a -> Maybe (f (Seq a)) I'm not sure if flabbergast can be made as fast as deleteLookup, so it's possible we may want both. Any opinions?

4 5

Update Read1 NonEmpty and Read1 Down
by Dannyu NDos 18 Dec '19

18 Dec '19

It would be better if liftReadPrec is used instead of liftReadsPrec. instance Read1 NonEmpty where liftReadPrec rp rl = paren $ prec 5 $ do x <- rp Symbol ":|" <- lexP xs <- rl pure (x :| xs)

1 0

joinAtomicallyWithMask, and a potential resource leak in http-client
by Leon Smith 12 Dec '19

12 Dec '19

I'm going to propose four new functions to add to the STM library, and would be interested in getting some feedback for this idea. The basic idea is that we implement these two functions, along with their WithUninterruptibleMask counterparts: {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} import Control.Monad(join) import Control.Concurrent.STM(STM, atomically) import Control.Exception(mask, mask_) joinAtomicallyWithMask :: STM ((forall a. (IO a -> IO a)) -> IO b) -> IO b joinAtomicallyWithMask transaction = mask $ \unmask -> do join . atomically $ do ioCont <- transaction return $ do ioCont unmask joinAtomicallyWithMask_ :: STM (IO b) -> IO b joinAtomicallyWithMask_ = mask_ . join . atomically However, the entire point of this endeavor is to implement these functions better than this. What we really want to do is to mask asynchronous exceptions in conjunction with an STM commit: a conservative implementation would upgrade the masking state shortly before we know if the transaction will commit or retry: if it retries, we restore the old masking state; if we commit, then we leave it alone. A perhaps more daring implementation would find a place immediately after commit before async exceptions could possibly appear, but this probably isn't necessary if the approach turns out to be too difficult/problematic. joinAtomicallyWithUninterruptibleMask actually allows us to express some programs that we couldn't before: will complete the STM transaction in an uninterruptible masking state, but we don't have to worry about blocking in the transaction because we won't have upgraded the masking state. I actually noticed this pattern twice recently: once in some code I was writing, and a second time within a week or two later, I noticed this would fix a potential resource leak in http-client, namely: https://github.com/snoyberg/http-client/blob/master/http-client/Data/KeyedP… reap destroy var = loop where loop = do threadDelay (5 * 1000 * 1000) join $ atomically $ do m'' <- readTVar var case m'' of PoolClosed -> return (return ()) PoolOpen idleCount m | Map.null m -> retry | otherwise -> do (m', toDestroy) <- findStale idleCount m writeTVar var m' return $ do mask_ (mapM_ (ignoreExceptions . destroy) toDestroy) loop It looks like to me that we really want to ensure that we call "destroy" on every resource taken out of the pool, but it would appear that the mask_ is somewhat misplaced: while perhaps it removes the most likely places that an asynchronous exception could break that invariant, it looks like there's still a possibility that an asynchronous exception that happens after the transaction commits but before the call to `mask_`. And lastly, I know I independently came up with the join . atomically idiom, but I know I'm not the first nor the last to do so. It's an idiom that does deserve to be more widely appreciated, and this could be a way to do it. Best, Leon

1 0

popCount is a method of Bits, not a FiniteBits
by Oleg Grenrus 03 Dec '19

03 Dec '19

I propose to change it to be member of FiniteBits I recall, there was a proposal to remove bitSize from Bits, so it's an opportunity to introduce another small, yet breaking change at the same time. Discussion time 2 week. - Oleg

6 11

Newtype wrapper for Float/Double with sensible Eq/Ord instances
by Zemyla 02 Dec '19

02 Dec '19

There should be a newtype wrapper that wraps a RealFloat, keeps the Enum/Num/Fractional/so on instances, but gives it sensible ones for Eq and Ord, with the following order: NaN < -Inf < negative < -0 < +0 < positive < +Inf It may not belong in base, but if nothing else it definitely belongs in containers, because Set and Map depend critically on sensible instances of Ord. (Also, it should newtype derive Read and Show, so that people using them with GHCi see "fromList [(NaN, yadda), (-1.5, yadda), (2.7, blah), (+Inf, blah)]" instead of "fromList [(FloatOrd { unwrapFloat :: NaN }, yadda), ...".)

3 3

Add NonEmptyMap and NonEmptySet to containers
by V.Liepelt 25 Nov '19

25 Nov '19

Hi John, I saw your thread about non-empty containers today. Why not call them `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? I think most agree that `NonEmpty` is not a great name—I couldn’t summarise it better than Andreas: "NonEmpty what?”. Hence I always do the following: ``` import Data.List.NonEmpty (NonEmpty) import qualified Data.List.NonEmpty as List1 type List1 = NonEmpty ``` In fact I just hoogled for this and noticed that the rebase package seems to do this too. More anecdotal precedent: recently a colleague wrote a datatype isomorphic to `(a, a, [a])` and called it something not quite as ridiculous as `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody involved was happy with that. Vilem

12 12