December 2013 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Removing MonadFail from Monad
by David Luposchainsky 03 Oct '14

03 Oct '14

Hey everyone, I feel like there are a couple of elephants in the room that are sort of important but nobody really addresses them directly. One of them was what became the AMP, and `fail` is another one. I resurrected and refurbished this proposal from a 6 month old Gist because there seemed to be some interest/talk going on in the form of side remarks in other discussions here. The sun shines, let's make some hay! The proposal text can be found at the end of this text (for the mailman archives), or in pretty HTML here: https://github.com/quchen/articles/blob/master/monad_fail.md Although this will technically a language-level change, the impact will mainly be a library and fail-safety detail. For this reason I think this mailing list is more suitable than other more specialized lists. Greetings, David/quchen PS: I would have chosen Fail Removal Proposal so we have a new buzzword, but unfortunately it does not abbreviate well. Call it the "fail of Haskell issue"? ;-) Removing `fail` from `Monad` ============================ The problem ----------- Currently, the `<-` symbol is desugared as follows: ```haskell do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` The problem with this is that `fail` cannot be sensibly implemented for many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to `error`, i.e. the monad has a built-in crash. `MonadFail` class ----------------- To fix this, introduce a new typeclass: ```haskell class Monad m => MonadFail m where fail :: String -> m a ``` Desugaring is then changed to the following: ```haskell -- Explicitly irrefutable pattern: do not add MonadFail constraint do ~pat <- computation >>> let f pat = more more >>> in computation >>= f -- Only one data constructor: do not add MonadFail constraint do (Only x) <- computation >>> let f (Only x) = more more >>> in computation >>= f -- Otherwise: add MonadFail constraint do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` Discussion ---------- - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class should be created. A parser might fail with an error message involving positional information, and for STM failure is undefined although it is `MonadPlus`. - The case of one data constructor should emit a warning if the data type is defined via `data`: adding another data constructor can make patterns in unrelated modules refutable. - Some monads use the pattern matching to force evaluation of the binding, for example lazy/strict `StateT`. I'm not sure what exactly the consequences of the above are here; I suspect a strictness annotation or `(>>=)` instead of `do` notation might be sufficient. - Getting the change to work should be boring but painless: all Monad instance declarations involving `fail` will break because the function is removed, and many monadic computations have to be annotated using `~` because they were written under the assumption that `fail` is never called. In both these cases compilation errors/warnings carry sufficient information to fix the source code easily. - Backwards compatibility with many old modules will be broken; I don't see a way around this. Other things to consider ------------------------ - Rename `fail`? It's quite a generic name that would be nice to have in APIs. `failM`? `mfail`? - Remove the `String` argument? (May hurt error reporting on pattern mismatch ..?) - How sensitive would existing code be to subtle changes in the strictness behaviour of `do` notation pattern matching? Applying the change ------------------- Like the AMP, 1. Implement ad-hoc warnings that code will receive a `MonadFail` constraint in a future version. "Either make the patterns irrefutable, or keep in mind that the next compiler version will require a `MonadFail` instance". Since `MonadFail` does not clash with an existing name, it could be introduced to `Control.Monad` right away. 2. Do the switch.

9 11

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Re: Add laws to Alternative
by Twan van Laarhoven 29 May '14

29 May '14

On 01/11/13 12:44, Nathan van Doorn wrote: > Firstly, I don't see how IO is relevant here, it has neither a MonadPlus > instance nor an Alternative instance. You are right. I thought it was an instance with mzero=fail "foo" and mplus=catch. But I was apparently mistaken. Objection withdrawn. > Secondly, the MonadPlus laws are documented in Control.Monad to be: > > mzero >>= f = mzero > v >> mzero = mzero I missed them, because they are written in the documentation of mzero rather than the documentation of the class where I expected them. > Thirdly, the monoid laws are already documented. (<|>) must be "An associative > binary operation", and empty "The identity of <|>". These are exactly the monoid > laws. Perhaps they should be made more explicit, but that is a different issue. Missed this as well. > Fourthly, [] fulfils neither the left-distribution law or the left-catch law, > and I doubt many people would be happy to lose []'s MonadPlus instance. List does satisfy left distribution: λ> (,) <$> ([1,2] <|> [3]) <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] λ> (,) <$> [1,2] <*> [4,5] <|> (,) <$> [3] <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] λ> quickCheck (\x y z -> ((,) <$> (x <|> y :: [Int]) <*> (z :: [Int])) == (((,) <$> x <*> z) <|> ((,) <$> y <*> z))) +++ OK, passed 100 tests. See also http://www.haskell.org/haskellwiki/MonadPlus. Then law which it doesn't is right distribution. Consider Maybe. it does satisfies left catch but not left distribution for MonadPlus. Since mplus (Just False >>= guard) (Just True >>= guard) = Just () while mplus (Just False) (Just True) >>= guard = Nothing But for Alternative, you can't have the failure of the second argument of (<*>) depend on the first. So Maybe *does* satisfy left distribution for Alternative. IMO that makes it a good candidate law. Twan > I believe I have addressed all your issues. If I've missed something, please > point it out to me. > > Nathan. > > > On 1 November 2013 12:09, Twan van Laarhoven <twanvl(a)gmail.com > <mailto:twanvl@gmail.com>> wrote: > > On 01/11/13 11:42, Nathan van Doorn wrote: > > Proposal: add the following laws to the documentation of > Control.Applicative.__Alternative: > > * empty <*> a = empty > * f <*> empty = empty > > > These laws correspond to the laws given in MonadPlus- if you take mzero = > > empty and ap = (<*>), the ones in MonadPlus imply these- and I don't think > > this proposal should be too controversial. > > As far as I can see, the documentation for MonadPlus does not specify these > laws anywhere [1,2]. > > Consider the IO monad. These laws claim that > > launchMissiles *> fail "empty" = fail "empty" > > This is clearly *not* true. > > -- > > If we add laws, I think we should first consider the much more reasonable > monoid laws > > identity > empty <|> a = a > a <|> empty = a > associativity: > (a <|> b) <|> c = a <|> (b <|> c) > > In the MonadPlus world, the controversial part is the choice between > > left distribution > (f <|> g) <*> a = (f <*> a) <|> (g <*> a) > > or > > left catch > pure a <|> b = pure a > > Your proposal would be > > left zero > > empty <*> a = empty > right zero > > f <*> empty = empty > > And as mentioned above, right zero is problematic. The fmap version should > be okay though > > map zero > f <$> empty = empty > > > Twan > > [1] > http://hackage.haskell.org/__package/base-4.6.0.1/docs/__Control-Monad.html… > <http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:M…> > [2] http://www.haskell.org/__haskellwiki/MonadPlus > <http://www.haskell.org/haskellwiki/MonadPlus> > _________________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://www.haskell.org/__mailman/listinfo/libraries > <http://www.haskell.org/mailman/listinfo/libraries> > >

9 11

Re: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by Thomas Schilling 29 Dec '13

29 Dec '13

Also, adding a function should bump the third component, not the fourth. On 11 December 2013 16:57, Thomas Schilling <nominolo(a)googlemail.com> wrote: > There's a typo in line: > > +#ifndef HAVE_FDAYASYNC > > I assume it should read HAVE_FDATASYNC > > Did you try to compile this on a system that has fdatasync? > > On 7 December 2013 20:20, Ricardo Catalinas Jiménez > <jimenezrick(a)gmail.com> wrote: >> Hi, >> >> Please review this pull request: >> https://github.com/jimenezrick/unix/compare/master...file-utils.patch >> >> If you find interesting this patch, then: >> git pull https://github.com/jimenezrick/unix.git file-utils >> >> /Ricardo >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries

6 12

cabal sandboxes executable path
by Konstantine Rybnikov 27 Dec '13

27 Dec '13

Hi! After I do `cabal install`, I get two binaries: - in `dist/dist-sandbox-$ID/build/Foo/Foo` - in `.cabal-sandbox/bin/Foo` They seem to be different. Is this ok? Which one of them is the right one? Sorry if I missed this in docs. Thanks.

4 6

Adding a finalizer to a TVar
by Sebastiaan Visser 23 Dec '13

23 Dec '13

Hi, Both MVar and IORef have specialized functions to attach a finalizer to there inner identifiable (stable) reference cell. I happen to need something similar for TVars, but that one doesn't seem to exist. The documentation of System.Mem.Weak tells me: "Finalizers can be used reliably for types that are created explicitly and have identity, such as IORef and MVar. However, to place a finalizer on one of these types, you should use the specific operation provided for that type, e.g. mkWeakIORef and addMVarFinalizer respectively (the non-uniformity is accidental). These operations attach the finalizer to the primitive object inside the box (e.g. MutVar# in the case of IORef), because attaching the finalizer to the box itself fails when the outer box is optimised away by the compiler." Does it make sense to add a similar function to the STM package? What I do now is hack around it by adding an IORef next to my TVar which I attach the finalizer to. Because my outer datatype is opaque I expect both variables to go out of scope and get garbage collected simultaneously. As you might expect, this isn't a very satisfiable solution. Thanks, Sebastiaan

4 3

Proposal: Add a strict version of <$> for monads
by Johan Tibell 22 Dec '13

22 Dec '13

Hi all, I propose we add a strict version of <$> to base: -- | A strict version of 'Data.Functor.<$>' for monads. (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do a <- m return $! f a {-# INLINE (<$!>) #-} infixl 4 <$!> It works on Monads instead of Functors as required by us inspecting the argument. This version is highly convenient if you want to work with functors/applicatives in e.g. parser and avoid spurious thunks at the same time. I realized that it was needed while fixing large space usage (but not space-leak) issues in cassava. I believe Edward Kmett discovered the need for it independently as well. Deadline: 3 weeks Cheers, Johan

13 26

Proposal: die to System.Exit (and/or Prelude)
by Simon Hengel 21 Dec '13

21 Dec '13

Hi! I propose to add die :: String -> IO () die err = hPutStrLn stderr err >> exitFailure to System.Exit. Reasoning: (1) It's a frequently required functionality. Almost every command-line program has code similar to this. (2) The definition is relatively short, but in addition to the definition, you need two import statements. (3) It's frequently done wrong (e.g. writing to stdout instead of stderr, or not using exitFailure, or both). I haven't done any extensive research on Hackage, but I quickly looked at Haddock. Here we have a definition of die [1], but we also print to stdout at a couple of place and then call exitFailure [2]. Personally, I think it should be re-exported from Prelude. But this may be controversial. So let's have two separate votes: Add System.Exit.die: +1 Re-export it from Prelude: +1 (discussion until December, 28th) Cheers, Simon [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429… [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c53893…

18 38