December 2019 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 13 Aug '20

13 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

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: [core libraries] Adding Backwards to base, re-export from Control.Applicative
by Baldur Blöndal 07 Jun '20

07 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

Remove MonadFail (ST s) instance
by Oleg Grenrus 06 Feb '20

06 Feb '20

I cannot see any justification for that instance -- | @since 4.11.0.0 instance Fail.MonadFail (ST s) where fail s = errorWithoutStackTrace s If someone wants to fail pattern matches in `ST s`, please do that explicitly. I suggest and propose the removal without any deprecation period. If someone depends on this behavior, they ought to fix they code immediately: it's straight forward compiler type-error driven refactoring. Note: compatibility package https://hackage.haskell.org/package/fail-4.9.0.0/docs/Control-Monad-Fail.ht… doesn't have that instance, so I suspect not-that many use(d) that instance. Discussion period: 2 weeks (until Monday 2019-12-09). - Oleg P.S. you might run into problems with https://gitlab.haskell.org/ghc/ghc/issues/15681 bug/miss-feature, but there's always a workaround to write code using explicit matching combinator, so it's not a show stopper.

14 23

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

14 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 14 Jan '20

14 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

Augmented sequence deletion
by David Feuer 29 Dec '19

29 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 13 Dec '19

13 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 04 Dec '19

04 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