August 2017 - Libraries

Removing bitSize
by David Feuer 05 Feb '18

05 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

FunctorFix
by Wolfgang Jeltsch 11 Sep '17

11 Sep '17

Hi! There is the MonadFix class with the mfix method. However, there are situations where you need a fixed point operator of type a -> f a for some f, but f is not necessarily a monad. What about adding a FunctorFix class that is identical to MonadFix, except that it has a Functor, not a Monad, superclass constraint? All the best, Wolfgang

5 18

Re: Let's rework Data.Type.Equality.==
by Ryan Scott 06 Sep '17

06 Sep '17

Personally, I'd be more inclined towards latter approach (in https://phabricator.haskell.org/D3837) After all, one of the key properties of (==) (for which the Haddocks even make a special note) is that it does not attempt to provide an instance that works for every possible kind. Indeed, as you've discovered, there are cases when it doesn't make sense to use DefaultEq, such as for (). I'll tentatively give my support for D3837, although I'd be curious to hear what Richard has to say about this (since I'm reasonably confident he gave (==) its current implementation). Ryan S.

5 8

Let's rework Data.Type.Equality.==
by David Feuer 02 Sep '17

02 Sep '17

The (==) type family in Data.Type.Equality was designed largely to calculate structural equality of types. However, limitations of GHC's type system at the type prevented this from being fully realized. Today, with TypeInType, we can actually do it, replacing the boatload of ad hoc instances like so: type (a :: k) == (b :: k) = Equal k a b infix 4 == type family Equal (k :: Type) (a :: k) (b :: k) where Equal k ((f :: j -> k) (a :: j)) ((g :: j -> k) (b :: j)) = Equal (j -> k) f g && Equal j a b Equal k a a = 'True Equal k a b = 'False This == behaves in a much more uniform way than the current one. I see two potential causes for complaint: 1. For types of kind *, the new version will sometimes fail to reduce when the old one succeeded (and vice versa). For example, GHC currently accepts eqeq :: forall (a :: *). proxy a -> (a == a) :~: 'True eqeq _ = Refl while the proposed version does not. 2. Some users may want non-structural equality on their types for some reason. The only example in base is type instance (a :: ()) == (b :: ()) = 'True which consists two types of kind () the same even if they're stuck types. But perhaps someone wants to implement a non-trivial type-level data structure with a special notion of equality. I don't think (1) is really worth worrying too much about. For (2), if users want to have control, we could at least use a mechanism similar to the above to make the obvious instances easier to write.

2 6

Reviving strict-concurrency
by Yitzchak Gale 29 Aug '17

29 Aug '17

The base library does not provide strict variants for the basic concurrency primitives. Instead, the haddocks for Control.Concurrent.MVar recommend using Don Stewarts's strict-concurrency library: https://hackage.haskell.org/package/strict-concurrency But that library has not been buildable for years. The homepage seems no longer accessible, and there is no source repository link. I created a github repo from the tarball for version 0.2.4.1 (the latest, from 2010), and then made the minor tweaks needed to get it build with modern GHC. The library provides no tests, so I have no idea if what I did still provides the advertised guarantees or even actually works. My repo is here: https://github.com/ygale/strict-concurrency Is the library still as critical as it used to be? Perhaps not in this age of async and STM, but to me it still makes sense to offer strict versions of these primitives. If so, then perhaps this small and simple library should be taken under the wing of libraries as maintainer. In any case, could someone please at least apply my patch and upload to hackage, so that it will be buildable again? I became aware of this because I was hoping to use vacuum for a complex debugging task, but vacuum also hasn't been buildable for several years due to its dependence on strict-concurrency. Whether vacuum will actually work after several years of neglect is a separate question. Thanks, Yitz

3 3

Does the streaming package need a new/additional maintainer?
by David Feuer 29 Aug '17

29 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 22 Aug '17

22 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