On Fri, 30 Nov 2012, Edward Kmett wrote:

You can add lens to the list of packages that had to define their own (for doctest purposes). ;)

I grepped for isLeft and isRight in lens-3.6 but did not find them.

On 2 December 2012 08:42, Andreas Abel wrote:

On 30.11.12 7:14 PM, Henning Thielemann wrote:

...

Agda uses isLeft and isRight in some QuickCheck properties. And then there is this application:

do -- ps0 :: [NamedArg ParseLHS] ps0 <- mapM classPat ps let (ps1, rest) = span (isLeft . namedArg) ps0 (p2, ps3) <- uncons rest -- when (null rest): no field pattern or def pattern found guard $ all (isLeft . namedArg) ps3 let (f, lhs) = fromR p2 (ps', _:ps'') = splitAt (length ps1) ps return $ Right (f, LHSProj x ps' lhs ps'')

Looks at least interesting ... :-)

Well, maybe this code could be improved, avoiding isLeft and fromR(ight).

Basically, what I want to to here is: - I have a list of things: ps - I have a classification of these things into Left and Right: classPat - I want to succeed if exactly one of these things is classified as a Right - I want to extract that Right thing, modify it a bit: lhs - I want to obtain all the Left things unchanged: ps' and ps''

These standard functions do not do the job: - partitionEithers: loses the order of my things - lefts/rights: ditto

How do they lose the order? Or do you mean lose the order of "This Left is before that Right"?

The crux here is that the standard list functions like filter, span, break etc. use "Bool" as decision type. They would be more general with Either, using Left as falsehood and Right as truth.

span :: (a -> Either b c) -> [a] -> ([c], [a]) break :: (a -> Either b c) -> [a] -> ([b], [a]) partition :: (a -> Either b c) -> [a] -> ([c], [b])

Isn't your either-based partition function just partitionEithers?

etc.

How would you do it?

Cheers, Andreas

-- Andreas Abel <>< Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

On Sat, 1 Dec 2012, Andreas Abel wrote:

On 30.11.12 7:14 PM, Henning Thielemann wrote:

...

Agda uses isLeft and isRight in some QuickCheck properties. And then there is this application:

do -- ps0 :: [NamedArg ParseLHS] ps0 <- mapM classPat ps let (ps1, rest) = span (isLeft . namedArg) ps0 (p2, ps3) <- uncons rest -- when (null rest): no field pattern or def pattern found guard $ all (isLeft . namedArg) ps3 let (f, lhs) = fromR p2 (ps', _:ps'') = splitAt (length ps1) ps return $ Right (f, LHSProj x ps' lhs ps'')

Looks at least interesting ... :-)

Well, maybe this code could be improved, avoiding isLeft and fromR(ight).

Basically, what I want to to here is: - I have a list of things: ps - I have a classification of these things into Left and Right: classPat - I want to succeed if exactly one of these things is classified as a Right - I want to extract that Right thing, modify it a bit: lhs - I want to obtain all the Left things unchanged: ps' and ps''

Since you know that everything in ps' and ps'' is Left, I guess it would be more precise to return the value without the Left constructor, right?

These standard functions do not do the job: - partitionEithers: loses the order of my things - lefts/rights: ditto

right

The crux here is that the standard list functions like filter, span, break etc. use "Bool" as decision type. They would be more general with Either, using Left as falsehood and Right as truth.

span :: (a -> Either b c) -> [a] -> ([c], [a]) break :: (a -> Either b c) -> [a] -> ([b], [a])

Since you do not use the 'b' type in 'span' and the 'c' type in 'break' we would certainly prefer: spanMaybe :: (a -> Maybe c) -> [a] -> ([c], [a]) breakMaybe :: (a -> Maybe b) -> [a] -> ([b], [a]) However for your application, something with an Either "predicate" would be actually more appropriate. Like breakEither :: (a -> Either b c) -> [a] -> ([b], Maybe (c, [a]))

How would you do it?

E.g. I would try to avoid the irrefutable pattern (_:ps''), since it is a potential source of an error. For now I can only come up with a mix of explicit recursion and standard library functions (partitionEithers): import Data.Tuple.HT (mapFst) import Control.Monad (guard) import Data.Either (partitionEithers) breakEither :: (a -> Either b c) -> [a] -> ([b], Maybe (c, [a])) breakEither f = let go [] = ([], Nothing) go (e : es) = case f e of Left x -> mapFst (x :) $ go es Right x -> ([], Just (x, es)) in go splitAtSingleRight :: [Either a b] -> Maybe ([a], b, [a]) splitAtSingleRight xs = case breakEither id xs of (as, msuffix) -> do (c,es) <- msuffix case partitionEithers es of (ls, rs) -> guard (null rs) >> return (as, c, ls)

On Tue, 4 Dec 2012, Herbert Valerio Riedel wrote:

btw, what I've been missing even more than isLeft/isRight is something like

leftMaybe :: Either a b -> Maybe a leftMaybe (Left x) = Just x leftMaybe _ = Nothing

rightMaybe :: Either a b -> Maybe b rightMaybe (Right x) = Just x rightMaybe _ = Nothing

These seem to be more useful for me than isLeft and isRight. However, I think I would prefer maybeLeft and maybeRight.

+1 for maybeLeft/maybeRight too On Tue, Dec 4, 2012 at 11:04 PM, Henning Thielemann wrote:

On Tue, 4 Dec 2012, Herbert Valerio Riedel wrote:

...

btw, what I've been missing even more than isLeft/isRight is something like

leftMaybe :: Either a b -> Maybe a leftMaybe (Left x) = Just x leftMaybe _ = Nothing

rightMaybe :: Either a b -> Maybe b rightMaybe (Right x) = Just x rightMaybe _ = Nothing

These seem to be more useful for me than isLeft and isRight.

However, I think I would prefer maybeLeft and maybeRight.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Your ship was destroyed in a monadic eruption.

Hi Herbert, On Tue, Dec 04, 2012 at 11:02:07PM +0100, Herbert Valerio Riedel wrote:

btw, what I've been missing even more than isLeft/isRight is something like

leftMaybe :: Either a b -> Maybe a leftMaybe (Left x) = Just x leftMaybe _ = Nothing

rightMaybe :: Either a b -> Maybe b rightMaybe (Right x) = Just x rightMaybe _ = Nothing

There seems to be support for this. I think it would be useful to have a separate proposal/patch. Cheers, Simon

On Wed, 5 Dec 2012, Daniel Fischer wrote:

On Mittwoch, 5. Dezember 2012, 09:23:31, Simon Hengel wrote:

...

Hi Herbert,

On Tue, Dec 04, 2012 at 11:02:07PM +0100, Herbert Valerio Riedel wrote:

...

btw, what I've been missing even more than isLeft/isRight is something like

leftMaybe :: Either a b -> Maybe a leftMaybe (Left x) = Just x leftMaybe _ = Nothing

rightMaybe :: Either a b -> Maybe b rightMaybe (Right x) = Just x rightMaybe _ = Nothing

There seems to be support for this. I think it would be useful to have a separate proposal/patch.

I'm not against it, but I would like to ask whether these are really used so frequently that

Prelude> :t either Just (const Nothing) either Just (const Nothing) :: Either a b -> Maybe a

is too cumbersome.

The same can be asked for Prelude> :t either (const False) (const True) either (const False) (const True) :: Either a b -> Bool or isLeft = isJust . maybeLeft

"Bryan O'Sullivan" writes:

On Wed, Dec 5, 2012 at 8:16 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

The same can be asked for

Prelude> :t either (const False) (const True) either (const False) (const True) :: Either a b -> Bool

or

isLeft = isJust . maybeLeft

We at least have evidence that isLeft and isRight are actually present in several packages. That helps this proposal squeak over my bar, so I'm +0 on it.

I think that maybeLeft and maybeRight are interesting, but the burden of proof for "these things solve a problem that actually exists" is a little higher. Consider me -0.01.

In general, I feel we have a fondness for a few too many near-trivial one-liners that make libraries bigger and harder to navigate, without really adding much expressivity.

fair enough, here's some motivation why I think that maybe{Left,Right} might be worth to be added (and to some degree maybe even their co/dual counterparts): - maybe{Left,Right} compose points-free conveniently with existing Data.Maybe primitives, e.g. - lefts = mapMaybe maybeLeft - isLeft = isJust . maybeLeft - fromLeft' default = fromMaybe default . maybeLeft - fromRight' default = fromMaybe default . maybeRight - maybeRight is used in at least two packages (I didn't have time to search for more, but if it makes a difference, I'll search Hackage for more use cases): - precis:Precis.Utils.ControlOperators.suppress - errors:Control.Error.Util.hush and also their dual (see fromRight' above) is defined there: - precis:Precis.Utils.ControlOperators.elaborate - errors:Control.Error.Util.note - from{Left,Right} are useful when working in the 'Maybe' monad or applicative functor for converting 'Either'-typed values (this also applies to the dual case of working in the 'Either' monad/app-functor and having to deal with 'Maybe' values) - IMHO, 'maybeRight' has better readability than inlining 'either (const Nothing) Just' - for me it's not so much about typing less, as more about having code that is easier to read out loud. - I often use the 'when'-like combinator 'whenJust' in monadic code: whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) a = a x whenJust _ _ = return () or simply defined as a type specialized 'forM_': whenJust = Data.Foldable.forM_ then the argument about composability with 'Maybe' stated above applies (imho): do result <- try $ foobar whenJust (maybeLeft result) $ \e -> do putStrLn $ "warning: got error during shutdown:" putStrLn $ " " ++ e return () this way I can avoid having to use a 'case of' expression with an explicit '_ -> return ()' branch for which I always struggle a bit how to indent it: do result <- try $ foobar case result of Left e -> do putStrLn $ "warning: got error during shutdown: " putStrLn $ " " ++ e _ -> return () return () - As the types in Data.Either and Data.Maybe are part of the Haskell standard library, and IMHO basic primitives such as maybe{Left,Right} should be located in those modules as well. cheers, hvr

+1 for Herberts proposal. On 06.12.12 6:41 AM, Herbert Valerio Riedel wrote:

- from{Left,Right} are useful when working in the 'Maybe' monad or applicative functor for converting 'Either'-typed values (this also applies to the dual case of working in the 'Either' monad/app-functor and having to deal with 'Maybe' values)

- IMHO, 'maybeRight' has better readability than inlining 'either (const Nothing) Just' - for me it's not so much about typing less, as more about having code that is easier to read out loud.

- I often use the 'when'-like combinator 'whenJust' in monadic code:

whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) a = a x whenJust _ _ = return ()

+1. whenJust is defined also in Agda.Utils.Monad, should also added to Control.Monad.

- As the types in Data.Either and Data.Maybe are part of the Haskell standard library, and IMHO basic primitives such as maybe{Left,Right} should be located in those modules as well.

+1 -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

On 6 December 2012 23:05, Evan Laforge wrote:

...

...

- I often use the 'when'-like combinator 'whenJust' in monadic code:

whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) a = a x whenJust _ _ = return ()

+1. whenJust is defined also in Agda.Utils.Monad, should also added to Control.Monad.

Off topic, but I have whenJust in my local library too, and I use it all the time.

In a project at work: $ grep -r whenJust --include=\*.hs . | wc -l 27

On 7 December 2012 10:25, Erik Hesselink wrote:

On Fri, Dec 7, 2012 at 9:29 AM, Bas van Dijk wrote:

...

On 6 December 2012 23:05, Evan Laforge wrote:

...

...

...

- I often use the 'when'-like combinator 'whenJust' in monadic code:

whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) a = a x whenJust _ _ = return ()

+1. whenJust is defined also in Agda.Utils.Monad, should also added to Control.Monad.

Off topic, but I have whenJust in my local library too, and I use it all the time.

In a project at work:

$ grep -r whenJust --include=\*.hs . | wc -l 27

There is no need to define whenJust, since it is just a specialization of forM_ from Data.Foldable.

Thanks for pointing this out! Replacing the 27 whenJusts as we speak... Bas

On 7 December 2012 09:25, Erik Hesselink wrote:

There is no need to define whenJust, since it is just a specialization of forM_ from Data.Foldable.

I don't know if that's such a good argument. I prefer my code readable -- too much abstraction can have a seriously bad effect on that. As a simple rule, if the user has to do type inference in their head, readability suffers. In this case, "forM_" implies we're iterating over something container like, "whenJust" means "I want to do something if this thing yielded a result". It depends on the context whether a "Maybe" is behaving more container-like or is indicating the presence of a result where there may not have been one. / Thomas

On Fri, 7 Dec 2012, Thomas Schilling wrote:

On 7 December 2012 09:25, Erik Hesselink wrote:

...

There is no need to define whenJust, since it is just a specialization of forM_ from Data.Foldable.

I don't know if that's such a good argument. I prefer my code readable -- too much abstraction can have a seriously bad effect on that. As a simple rule, if the user has to do type inference in their head, readability suffers.

In this case, "forM_" implies we're iterating over something container like, "whenJust" means "I want to do something if this thing yielded a result". It depends on the context whether a "Maybe" is behaving more container-like or is indicating the presence of a result where there may not have been one.

Too much abstraction can certainly reduce readability. In this case I interpret Maybe as a list that can contain at most one element. This way I can use all the nice functions from Data.Foldable for Maybe.

On 10 December 2012 23:55, Simon Marlow wrote:

(I'd rather not use `either`, it's one of those functions whose type I always have to look up)

{-# LANGUAGE TypeSignatureRhymes #-} either :~: do something with the left or something with the right but either way give me something of the same type Conrad.