October 2017 - 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

Removing bitSize
by David Feuer 04 Feb '18

04 Feb '18

The long-deprecated bitSize method of the Bits class is slated to be removed in base-4.11 (GHC 8.4). There is one remaining question: should we replace it with a *function* by that name with a FiniteBits constraint? I don't feel very strongly either way, but Ryan Scott seems in favor and Edward Kmett seems opposed. So it seems best to bring it to the libraries list and let the CLC make the call. If the function is added, it would look like this: bitSize :: FiniteBits a => a -> Int bitSize = finiteBitSize The biggest downside I see is that we might one day want to reuse the name for something with a better type, such as bitSize :: forall proxy a. FiniteBits a => proxy a -> Int bitSize _ = finiteBitSize (undefined :: a) or bitSize :: forall a. FiniteBits a => Tagged a Int bitSize = Tagged (finiteBitSize (undefined :: a)) or (with type applications) bitSize :: forall a. FiniteBits a => Int bitSize = finiteBitSize (undefined :: a) Thanks, David Feuer

5 5

Maintenance of streaming and streaming-bytestring
by Andrew Martin 11 Dec '17

11 Dec '17

David Feuer brought this up two weeks ago [0]. The maintainer of streaming and streaming-bytestring has been unreachable, and provided his continued absence, I would like to become a maintainer of these two libraries. I have put up PRs fixing issues [1] and I've offered on the issue tracker to become a comaintainer [2]. I use this library a lot at work, so I have an interest in keeping it in good shape. [0] https://mail.haskell.org/pipermail/libraries/2017-August/028141.html [1] https://github.com/michaelt/streaming-bytestring/pull/11 [2] https://github.com/michaelt/streaming-bytestring/issues/19 -- -Andrew Thaddeus Martin

6 12

Proposal: add ordNub somewhere in containers
by Gershom B 13 Nov '17

13 Nov '17

There have been many discussions over the years about adding an efficient order preserving nub somewhere to our core libraries. It always comes down to the same issue: an efficient nub wants to be backed by an efficient `Set`, but the API of the `nub` itself doesn't make reference to any other data structures besides lists. So it feels a bit conceptually strange to put an efficient nub anywhere besides `Data.List` even though it can't go there without inverting our dependency tree in a weird way or inlining an efficient set implementation into the middle of it. Nonetheless, the convenience of having a good `nub` lying around in a core library is undeniable, and after writing the "usual" one in my code for the zillionth time, I decided to raise an issue about it: https://github.com/haskell/containers/issues/439 I was promptly directed here to make a proper proposal. So, here: 1) I propose two new functions, `ordNub` and `intNub` with the standard implementation (from https://github.com/nh2/haskell-ordnub) import qualified Data.Set as Set ordNub :: (Ord a) => [a] -> [a] ordNub l = go Set.empty l where go _ [] = [] go s (x:xs) = if x `Set.member` s then go s xs else x : go (Set.insert x s) xs and the same implementation, but specialized to `Int` and using `IntSet`s. The rationale for the names is that the former has a long history of use in folklore, and the latter is the obvious specialization of it. 2) I propose these functions be added to a new module in the `containers` library: `Data.Containers.ListUtils`. This can also potentially in the future add efficient list intersection, etc. as documented on the above reference link. The rationale for the new module is that it can provide a meaningful home for such functions which operate on lists, but require other data structures to be implemented efficiently... Discussion period: 2 weeks. --Gershom

13 25

Proposal: Add "Alternative" instance for ZipList, as well as Semigroup and Monoid
by Zemyla 21 Oct '17

21 Oct '17

This paper on monoids and near-semirings gives an Alternative instance for ZipList consistent with its Applicative instance: https://lirias.kuleuven.be/bitstream/123456789/499951/1/main.pdf The original definition of (<|>) leaves a lot to be desired, because it iterates through the first list twice, preventing inlining of xs: ZipList xs <|> ZipList ys = ZipList $ xs ++ drop (length xs) ys Edited for efficiency, it winds up being: instance Alternative ZipList where empty = ZipList [] ZipList xs <|> ZipList ys = ZipList $ go xs ys where go [] ys = ys go xs [] = xs go (x:xs) (_:ys) = x:go xs ys A different formulation, using foldr/build, goes like this: ZipList xs <|> ZipList ys = ZipList $ build $ \c z -> let goX x xr !n = c x $ xr $ n + 1 goY y yr n | n <= 0 = c y $ yr 0 | otherwise = yr $ n - 1 in foldr goX (foldr goY (const z) ys) ys (0 :: Int) It is an idempotent monoid, and sconcat/mconcat can be written as follows: zlconcat :: Foldable t => t (ZipList a) -> ZipList a zlconcat xss = ZipList $ build $ \c z -> let goO (ZipList xs) xr !n = foldr goI endI xs 0 where goI x xk i | i < n = xk $ i + 1 | otherwise = c x $ xk $ i + 1 endI i = if i < n then xr n else xr i in foldr goO (const z) xss (0 :: Int) So in the end, the Semigroup/Monoid instances look like: instance Semigroup (ZipList a) where (<>) = (<|>) sconcat = zlconcat stimes = stimesIdempotentMonoid instance Monoid (ZipList a) where mempty = empty mappend = (<|>) mconcat = zlconcat Sadly, the paper doesn't prove that it's a valid left catch Alternative, and sort of mentions it offhand, but tests suggest it is associative, [] is obviously the identity for <|> and the zero for <*>, and pure a <|> x = pure a. Any ideas on which implementation to prefer, or different ideas for implementing sconcat/mconcat?

1 0

documentation bug in base
by Ben Franksen 15 Oct '17

15 Oct '17

Data.List claims: unlines is an inverse operation to lines. which I understand to mean prop> unlines (lines s) = s which is false in general. It should say prop> unlines (lines s) = if last s == '\n' then s else s ++ "\n" Cheers Ben

1 0

Proposal: Taking over/up network maintainership
by Merijn Verstraaten 12 Oct '17

12 Oct '17

Hi hackage admins & libraries@ readers, So, to the best of my knowledge 'network' is currently maintained by libraries@/the community, which is code for "not maintained". I've previously entertained the thought of taking up maintainership, but so far was held back by the fact that I don't do windows dev experience. I've discussed this in #ghc before and the consensus was that *nix only maintenance is probably still better than no maintenance. I was inspired to finally write this email and try to take up maintenance after spending all day yesterday tomorrow debugging an issue in my code, only to realise that Network.ByteString.Lazy.getContents will literally *always* crash/throw an exception when used. My plans are to: Short term: fix obvious errors like getContents, cut through the PR backlog on github to see what can be merged, what needs work, etc. Medium term: Improve exception/error handling (network specific exception type that people can catch), better (async) exceptions safety guarantees/documentation of safety Long term: I would like ditch the current (deprecated) high-level interface and replace it with modern high level API. Now, the biggest problem is that I don't have experience developing on Windows and neither the time nor the motivation to get started with that, so I will need someone to take up co-maintainership of the windows parts (I'll probably send an email about this to -cafe if people are supportive of me taking up maintenance). Cheers, Merijn

6 7