January 2019 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 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

Contacting bytestring-trie maintainers
by Tim McGilchrist 06 Feb '19

06 Feb '19

Hi All, I am trying to get in touch with the maintainers for bytestring-trie package ( http://hackage.haskell.org/package/bytestring-trie ), which appears to be Wren Romano. I have a patch to fix issues with GHC 8.4 support. I have sent 2 emails over the last few months using the contact details in the cabal file and haven’t received a reply. Email attached below. Could I ask if someone has a better contact address or is able to pass on the email that they would. Failing that I’d like to get access to push the fix to hackage without the need for making a forked package. Cheers, Tim McGilchrist ——————————————————— Hi Wren, I'm using your bytestring-trie library in a package (airship) and wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. Please find attached a minor patch to add support which is mainly concerned with adding the Semigroup instances required. If you're happy with the changes I'd also appreciate a new release of the package to hackage. Regards, Tim McGilchrist

4 7

Order of constructors in Data.Map.Internal
by chessai . 03 Feb '19

03 Feb '19

When looking through the source of Data.Map.Internal, there's a note: -- [Note: Order of constructors] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- The order of constructors of Map matters when considering performance. -- Currently in GHC 7.0, when type has 2 constructors, a forward conditional -- jump is made when successfully matching second constructor. Successful match -- of first constructor results in the forward jump not taken. -- On GHC 7.0, reordering constructors from Tip | Bin to Bin | Tip -- improves the benchmark by up to 10% on x86. I've been curious about this for a while now. GHC 7.0 was released quite a long time ago, so I wonder if this is still the case? David might know.

2 3

Re: Applicative-based definitions in Data.Foldable
by Isaac Elliott 24 Jan '19

24 Jan '19

I used `anyA` today, to run predicates on things contained in IORefs. On Fri, Dec 21, 2018 at 10:37 AM Isaac Elliott <isaace71295(a)gmail.com> wrote: > With the introduction of the 'Ap' monoid in base-4.13, it seems like > Applicative based definitions for common folds would be appropriate in base. > > For example: > >> allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool >> allA f = fmap getAll . getAp . foldMap (Ap . fmap All . f) >> > > >> all :: Foldable t => (a -> Bool) -> t a -> Bool >> all f = runIdentity . allA (Identity . f) > > > I've personally written the Applicative version in everyday code. Thoughts? > > Isaac >

1 0

postgresql-simple broken in GHC 8.6.3 on Windows
by Yitzchak Gale 22 Jan '19

22 Jan '19

First of all, many thanks to Oleg for taking on maintainership of postgresql-simple. Oleg, your new github fork of postgresql-simple - which is now the official source of this package - does not have issues enabled. Where is the right place to report issues? In particular, the library is not building for us on Windows with GHC 8.6.3. One of our devs has a guess that it's related to GHC bug #16057. In any case, we'd like to file an issue for postgresql-simple. https://ghc.haskell.org/trac/ghc/ticket/16057 The evidence that this GHC bug may be at play is that compilation hangs in Database.PostgreSQL.Simple.FromField, which uses some TH splices. That is the same behavior we are seeing for ofther packages that are hit by this GHC bug on Windows. Thanks, Yitz

2 2

Discussion: traversals for Data.Set
by David Feuer 21 Jan '19

21 Jan '19

Julian Ospald has opened a pull request[*] for containers to add a traversal operation to Data.Set. Julian specifically requested forM :: (Ord b, Monad m) => Set a -> (a -> m b) -> m (Set b) Personally, I think it would be better to offer the unflipped versions: -- The most general version traverse :: (Ord b, Applicative f) => (a -> f b) -> Set a -> f (Set b) traverse f = fmap fromList . traverse f . toList -- A more efficient, strictly accumulating version for "strict" -- monads like IO, strict State, etc. mapM :: (Ord b, Monad m) => (a -> m b) -> Set a -> m (Set b) mapM f s0 = foldr go return s0 empty where go x r s = f x >>= \y -> r $! insert y s The latter can also be written, perhaps less efficiently, as mapM :: (Ord b, Monad m) => (a -> m b) -> Set a -> m (Set b) mapM f = foldM go empty where go s x = f x >>= \y -> pure $! insert y s As usual, the main question is what names are appropriate. Typically, containers assumes that users import its modules qualified, and therefore we should just use `traverse` and `mapM`. But clashing with well-known and widely-used names often causes breakage anyway, so I figured I should bring the matter to the libraries list. Thanks, David Feuer [*] https://github.com/haskell/containers/pull/592

2 1

Request for review of proposed strict-concurrency improvements
by Yitzchak Gale 19 Jan '19

19 Jan '19

During the past few days, David Feuer has proposed a number of improvements to the strict-concurrency library. Thanks very much for this work! That, in turn, was triggered by some ideas of Eric Crockett - again, thanks very much for this! Since there are some subtle nuances at play here, I am asking the community to give this a brief review. Please comment directly in the PRs or issues, links below, not here on the list. Absent any comments, I will merge these PRs in about a week. If it's needed sooner than that, please let me know. Thanks, Yitz PRs: https://github.com/ygale/strict-concurrency/pull/9 https://github.com/ygale/strict-concurrency/pull/10 Issues: https://github.com/ygale/strict-concurrency/issues/2 https://github.com/ygale/strict-concurrency/issues/3 https://github.com/ygale/strict-concurrency/issues/4 https://github.com/ygale/strict-concurrency/issues/5 https://github.com/ygale/strict-concurrency/issues/6 https://github.com/ygale/strict-concurrency/issues/7 https://github.com/ygale/strict-concurrency/issues/8

1 0

Re: Asynchronous exceptions in threadWait
by Bev 17 Jan '19

17 Jan '19

Who are all you people and why am I receiving emails from you? Please stop. Take me off list. Thanks On Thursday, January 17, 2019 Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: Ah, that makes sense. They certainly differ in the guarantees they provide around when unregisterFd_ is called. Although I think the exception would still be raised in the caller of threadWait regardless of which way it was written. Sent from my iPhone > On Jan 17, 2019, at 5:58 PM, Michael Walker <mike(a)barrucadu.co.uk> wrote: > > So, something like this? > > threadWait :: Event -> Fd -> IO () > threadWait evt fd = do > (m, mgr, reg) <- mask_ $ do > m <- newEmptyMVar > mgr <- getSystemEventManager_ > reg <- registerFd mgr (\_ e -> putMVar m e) fd evt M.OneShot > pure (m, mgr, reg) > evt' <- takeMVar m `onException` unregisterFd_ mgr reg > if evt' `eventIs` evtClose > then ioError $ errnoToIOError "threadWait" eBADF Nothing Nothing > else return () > > I'm not sure this is semantically equivalent. > > GHC can pre-empt a thread whenever it allocates memory, and I assume > it can deliver exceptions at that granularity too. So if > `onException` allocates memory before the exception handler is set up, > then an exception could possibly be delivered in that brief window, > which would result in `unregisterFd_ mgr reg` never being called, and > an exception being raised in the caller of `threadWait`. > >> On Thu, 17 Jan 2019 at 22:43, Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: >> >> Thanks. That makes sense. So, in the code I’m looking at, since takeMVar is the last effectful thing that happens, there is no semantic difference between having mask_ extend all the way down to the bottom of the block (as it currently does) and cutting it off right before the line involving takeMVar? >> >> Sent from my iPhone >> >> On Jan 17, 2019, at 5:23 PM, Michael Walker <mike(a)barrucadu.co.uk> wrote: >> >>>> Although the entire function has asynchronous exceptions masked, the call to takeMVar uses onException to deal with the possibility of an exception. According to the docs in Control.Concurrent, takeMVar can throw exceptions. But my understand (which may be wrong) is that the only exception this could throw would be something like BlockedIndefinitelyOnMVar, which I don't believe can happen here. >>> >>> That's not quite right. The mask_ function blocks asynchronous >>> exceptions from being delivered to the thread while it's not >>> "interruptible". Most blocking functions, such as takeMVar, make the >>> thread interruptible while they're blocked. So any asynchronous >>> exception (such as ThreadKilled) could be delivered to the thread if >>> it blocks in the takeMVar. >>> >>> -- >>> Michael Walker (http://www.barrucadu.co.uk) > > > > -- > Michael Walker (http://www.barrucadu.co.uk) _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Asynchronous exceptions in threadWait
by Andrew Martin 17 Jan '19

17 Jan '19

3 6