November 2019 - Libraries

Re: Proposal: Laws for mtl classes
by Li-yao Xia 18 Nov '19

18 Nov '19

Hello Libraries, Some time ago I proposed some laws for the most common mtl classes (State, Reader, Error): https://mail.haskell.org/pipermail/libraries/2019-April/029549.html To address some concerns about completeness I reorganized the laws into groups describing more high-level properties, and formalized them in Coq to ensure the laws are strong enough to lift themselves through common transformers (StateT, ExceptT, ContT; ReaderT and WriterT are similar to StateT, but formalizing that relationship also makes the laws interact in interesting ways). I'm open to suggestions for better ways to verify the "completeness" of the laws. However, as long there aren't any objections to the existing laws themselves, it still seems worth having some documentation earlier rather than never. In the end the actual changes to the initial proposal were quite minor. Feel free to weigh in on the following pull requests: https://github.com/haskell/mtl/pull/61 (MonadReader, MonadState) https://github.com/haskell/mtl/pull/62 (MonadError) --- # Changes 1. Three laws were added, In MonadReader, > local id = id to complete the property that local is a monoid homomorphism (rather than only semigroup); thanks to Andreas Abel for pointing out its absence in the initial proposal. > local f u = ask >>= \s -> local (\_ -> f s) u This law was necessary to verify ContT's MonadReader instance. ContT is not actually lawful, but a certain subset of it seems to be (the elements of ContT that satisfy the commutativity of ask). I did not manage to find out whether it's implied by the other laws. In MonadError, a naturality law > fmap f (catchError u h) = catchError (fmap f u) (fmap f . h) whose need arose when describing the relationship between StateT's and ReaderT's instances. 2. Another finding is the fact that, much like the laws of MonadState are equivalent to saying that 'state' is a monad morphism, the 'ask' fragment of MonadReader (which to many *is* MonadReader) can also be characterized by a monad morphism, which cannot be 'reader', as it only yields two of the 'ask' laws. 3. There were two mistakes in the original proposal. One MonadError law was too strong: > catchError (m >>= k) h = tryError m >>= either h k -- broken by StateT And local should flip the order of composition > local g . local f = local (g . f) -- wrong > local g . local f = local (f . g) -- right --- # Updated proposal ## MonadState > get >>= put = pure () > put s >> get = put s >> pure s > put s1 >> put s2 = put s2 Those three laws imply the following equations expressing that get has no side effects: > get >> m = m > get >>= \s1 -> get >>= \s2 -> k s1 s2 = get >>= \s -> k s s state must be equivalent to its default definition in terms of get and put, and conversely. Under that last condition, a property which is equivalent to the laws above is that state must be a monad morphism, from State s to m. --- ## MonadReader ask has no side effects, and produces the same result at any time. > ask >> m = m > ask >>= \s1 -> ask >>= \s2 -> k s1 s2 = ask >>= \s -> k s s > > m <*> ask = ask <**> m local f applies f to the environment produced by ask. > local f ask = f <$> ask > local f u = ask >>= \s -> local (\_ -> f s) u local is a monoid morphism from (r -> r) to (reversed) (m a -> m a) (i.e., (Endo r -> Dual (Endo (m a)))). > local id = id > local g . local f = local (f . g) local is a monad morphism from m to m. > local f (pure x) = pure x > local f (a >>= k) = local f a >>= \x -> local f (k x) reader must be equivalent to its default definition in terms of ask, and conversely. Under that last condition, a property which is equivalent to the first two laws is that reader must be a monad morphism from Reader r to m. Another property equivalent to the first three laws is that there is a monad morphism phi :: forall a. ReaderT r m a -> m a such that phi ask = ask and phi . lift = id. --- ## MonadError See also Exceptionally Monadic Error Handling, by Jan Malakhovski: https://arxiv.org/abs/1810.13430 catchError and throwError form a monad, with (>>=) interpreted as catchError and pure as throwError. > catchError (throwError e) h = h e > catchError m throwError = m > catchError (catchError m k) h = catchError m (\e -> catchError (k e) h) pure and throwError are left zeros for catchError and (>>=) respectively. > catchError (pure a) h = pure a > throwError e >>= k = throwError e catchError commutes with fmap (it is a natual transformation). > fmap f (catchError u h) = catchError (fmap f u) (fmap f . h) --- Li-yao Xia

3 3

A bug with Sum (as in Monoid)
by Dannyu NDos 12 Nov '19

12 Nov '19

Sum has bug with floating points. Current definition states +0 as the identity element, while the actual identity is -0 since +0 + -0 = +0.

5 7

Exposed # kinded variables + polykinded Prelude classes?
by Zemyla 06 Nov '19

06 Nov '19

I'm wondering if there would be a benefit, if not to the average programmer, then to the ones working on deeper/faster code, to allow some of the # kinded types (mostly Int#, Word#, Char#, Float#, Double#) to be used in Safe code, and to have typeclasses able to work with them. For instance, the definition of Show would become: class Show (a :: TYPE r) where show :: a -> String default show :: (r ~ 'LiftedRep) => a -> String show x = showsPrec 0 x "" showsPrec :: Int -> a -> ShowS default showsPrec :: (r ~ 'LiftedRep) => Int -> a -> ShowS showsPrec _ x s = show x ++ s showList :: (r ~ 'LiftedRep) => [a] -> ShowS showList ls s = showList__ shows ls s The fact that the defaults only work when the type is a LiftedRep is a nonissue, because there's only a finite number of non-lifted types we'd be defining it for. You could do the same with Eq, Ord, Num, Real, Integral, Fractional, Floating, RealFrac, RealFloat, Semigroup, Monoid, Bits, FiniteBits, and probably several others I can't think of right now. However, with the functions that return pairs, you'd need a version that returns an unboxed pair instead. Assuming you changed ReadPrec, you could even do the same with Read: newtype ReadP (a :: RuntimeRep r) = ReadP (forall b. (a -> R b) -> R b) newtype ReadPrec (a :: RuntimeRep r) = ReadPrec (Int -> ReadP a) IO, ST, and STM could be made polykinded the same way, and would open up Storable. However, how to do a definition for Monad that works for polykinded monads is an issue. I do know that RebindableSyntax handles it easily when there's just one monad that can operate on multiple kinds, though. As for which # types could be exposed, I'm thinking that Char#, Int#, Word#, Float#, Double#, and Proxy# wouldn't be able to break out of Safe code. Int64# and Word64# would work as well, and for 64-bit machines would just be type aliases for Int# and Word# respectively. For types which have functions with undefined behavior for some arguments, you can just make wrappers that check the arguments and error out for the bad values. MutVar#, MVar#, TVar#, and StableName# don't open up any functions that would be unsuitable for safe code, either. I'm pretty sure that Array# and MutableArray# would also be safe, as long as all functions were length-checked and threw errors instead of having undefined behavior. As for why this would be a desirable thing? Mostly for the sake of convenience and generality, I think. I find myself working with unboxed values from time to time, and it's a pain to always remember to use (+#) for Int# and plusWord# for Word#. In addition, having typeclasses that can return unboxed values (like a hypothetical sized# :: Sized a => a -> Int# vs sized :: Sized a => a -> Int) can improve the generated code when the code using the typeclass doesn't get specialized. The module to import these would have to explain the differences between # kinded types and * kinded ones: # values aren't lazy; they can't be top-level definitions; you can't use unboxed tuples or sums with GHCi; and with a few exceptions, you can't place them in containers (you can't have an [Int#], for instance).

5 5

Add instance Data a => Data (ZipList a) to base
by Mario 04 Nov '19

04 Nov '19

I'm surprised this is missing. All newtypes exported from Control.Applicative share the same issue, with the exception of Const.

5 4

Expired certificate for prime.haskell.org
by Simon Jakobi 01 Nov '19

01 Nov '19

Hi! I just wanted to give someone a link to the Semigroup-Monoid-proposal, but couldn't open the page in Chromium: https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid There's already a short email thread regarding the issue from April on the haskell-prime mailing list: https://mail.haskell.org/pipermail/haskell-prime/2019-April/004448.html It would be nice if proposals like the SMP remained accessible! Cheers, Simon

2 3

bitSize both required and deprecated
by chessai . 01 Nov '19

01 Nov '19

All, In Data.Bits.Bits, `bitSize` has been marked deprecated for a while. but in 4.12, it was also given a default implementation. The issue is that it is in the minimal pragma as a required method. So, if I define it, I get a deprecation warning, but if I don't define it, I get a warning about missing implementations. Is this the intended behaviour? Thanks

4 3