darcs patch: Adding isLeft, isRight, fromLeft, fromRight, splitEithers
Mon Oct 30 14:28:19 CET 2006 Russell O'Connor
splitEithers (the Either counterpart of catMaybes) is a great idea. (Except maybe for the name; all these split's are getting confusing.) See also mapEither (the counterpart of mapMaybe) in Data.Map. I'm not so keen on isLeft, isRight, fromLeft and fromRight. Pattern matching is clearer and safer: at the point you make the decision, the type system has the extra information about the branch you've chosen. It also pushes the programmer to put the decision and the use of the data together, another good thing. The isJust/fromJust combination is already a rich source of bugs; we don't need more. (Same goes for null/head/tail, of course.)
Hello Ross, Tuesday, October 31, 2006, 11:59:56 AM, you wrote:
splitEithers (the Either counterpart of catMaybes) is a great idea. (Except maybe for the name; all these split's are getting confusing.) See also mapEither (the counterpart of mapMaybe) in Data.Map.
I'm not so keen on isLeft, isRight, fromLeft and fromRight. Pattern matching is clearer and safer: at the point you make the decision, the type system has the extra information about the branch you've chosen. It also pushes the programmer to put the decision and the use of the data together, another good thing. The isJust/fromJust combination is already a rich source of bugs; we don't need more. (Same goes for null/head/tail, of course.)
nevertheless, we want to use them all :) "don't teach me a life, just give some money :)" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 10/31/06, Bulat Ziganshin
I'm not so keen on isLeft, isRight, fromLeft and fromRight. Pattern matching is clearer and safer: at the point you make the decision, the type system has the extra information about the branch you've chosen. It also pushes the programmer to put the decision and the use of the data together, another good thing. The isJust/fromJust combination is already a rich source of bugs; we don't need more. (Same goes for null/head/tail, of course.)
What? Type system? Type system doesn't have anything to do with pattern match failure!
On Tue, Oct 31, 2006 at 02:20:04PM +0300, Bulat Ziganshin wrote:
nevertheless, we want to use them all :) "don't teach me a life, just give some money :)"
Sure. Meanwhile over at http://hackage.haskell.org/trac/ghc/ticket/960 we have yet another discussion of how to track down the runtime errors that result from this style.
Hi
nevertheless, we want to use them all :) "don't teach me a life, just give some money :)"
Sure. Meanwhile over at http://hackage.haskell.org/trac/ghc/ticket/960 we have yet another discussion of how to track down the runtime errors that result from this style.
The answer is Catch [1], which will soon handle all these sorts of problems and more :) Thanks Neil [1] http://www-users.cs.york.ac.uk/~ndm/projects/catch.php
Hello Ross, Tuesday, October 31, 2006, 5:40:12 PM, you wrote:
On Tue, Oct 31, 2006 at 02:20:04PM +0300, Bulat Ziganshin wrote:
nevertheless, we want to use them all :) "don't teach me a life, just give some money :)"
Sure. Meanwhile over at http://hackage.haskell.org/trac/ghc/ticket/960 we have yet another discussion of how to track down the runtime errors that result from this style.
it's just part of business. if you will give to consumer bug-free program, you can't charge for program support :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 10/31/06, Bulat Ziganshin
it's just part of business. if you will give to consumer bug-free program, you can't charge for program support :)))
Um, we don't! (What is a "consumer", by the way?)
Hello Samuel, Wednesday, November 1, 2006, 6:03:46 AM, you wrote:
it's just part of business. if you will give to consumer bug-free program, you can't charge for program support :)))
Um, we don't! (What is a "consumer", by the way?)
definitely, you are not goes through MBA school consumers are the peoples that eat your product, stare at your product and sleep with your product -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Samuel,
Wednesday, November 1, 2006, 6:03:46 AM, you wrote:
it's just part of business. if you will give to consumer bug-free program, you can't charge for program support :)))
Um, we don't! (What is a "consumer", by the way?)
definitely, you are not goes through MBA school
consumers are the peoples that eat your product, stare at your product and sleep with your product
Well, if this is your approach, I should be confident about your products but fearful of your sums. Conor
On Tue, 31 Oct 2006, Ross Paterson wrote:
On Tue, Oct 31, 2006 at 02:20:04PM +0300, Bulat Ziganshin wrote:
nevertheless, we want to use them all :) "don't teach me a life, just give some money :)"
Sure. Meanwhile over at http://hackage.haskell.org/trac/ghc/ticket/960 we have yet another discussion of how to track down the runtime errors that result from this style.
Today I'm also struggling with early uses of fromJust. fromMaybe (error "function X was not called corectly") is much better. I vote for not adding isLeft and fromLeft, 'either' is a good and safe thing.
On 30/10/06, Russell O'Connor
* Adding isLeft, isRight, fromLeft, fromRight, splitEithers
It'd be nice to have the following, too: lefts :: [Either a b] -> [a] lefts = fst . splitEithers rights :: [Either a b] -> [b] rights = snd . splitEithers -- -David House, dmhouse@gmail.com
Hello David, Tuesday, October 31, 2006, 1:23:19 PM, you wrote:
* Adding isLeft, isRight, fromLeft, fromRight, splitEithers
It'd be nice to have the following, too:
lefts :: [Either a b] -> [a] lefts = fst . splitEithers rights :: [Either a b] -> [b] rights = snd . splitEithers
i think that this may be faster: lefts = filter isLeft rights = filter isRight -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, 31 Oct 2006, Bulat Ziganshin wrote:
It'd be nice to have the following, too:
lefts :: [Either a b] -> [a] lefts = fst . splitEithers rights :: [Either a b] -> [b] rights = snd . splitEithers
i think that this may be faster:
lefts = filter isLeft rights = filter isRight
filter isLeft produces the wrong type. I believe the correct definition is: lefts x = [a | (Left a) <- x] rights x = [a | (Right a) <- x] -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
Hello Russell, Monday, October 30, 2006, 4:35:45 PM, you wrote:
* Adding isLeft, isRight, fromLeft, fromRight, splitEithers
two minor points: first, please add ',' to the end of export list. second, isn't "Either.fromLeft: Received Right" should be "Either.fromLeft: received Right" - i.e. with lowercased 'received'? in general, i suggest adding of ',' to the end of export list for all patches we does -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, 31 Oct 2006, Bulat Ziganshin wrote:
Monday, October 30, 2006, 4:35:45 PM, you wrote:
* Adding isLeft, isRight, fromLeft, fromRight, splitEithers
two minor points: first, please add ',' to the end of export list. second, isn't "Either.fromLeft: Received Right" should be "Either.fromLeft: received Right" - i.e. with lowercased 'received'?
in general, i suggest adding of ',' to the end of export list for all patches we does
Okay, when correcting a patch, should I ammend-record it, make a new patch, or bundle two dependent patches together? I'm thinking of separating out the controversial isLeft, isRight, fromLeft, and fromRight from this patch, and focus on the less contravertial splitEithers. Actually, I'm starting to like the name unzipEithers, so I propose changing this patch to add only unzipEithers, lefts, and rights. We can then consider isLeft, isRight, fromLeft, and fromRight on another thread. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
Hi
I'm thinking of separating out the controversial isLeft, isRight, fromLeft, and fromRight from this patch, and focus on the less contravertial splitEithers.
NOOOOOOO!!! Those are the best bits in this patch! If you want to propose removing head/tail/fromJust/isJust from Haskell, enhancing the type system to catch this and requiring a dependantly typed proof of every function - fine. But from a pragmatics point of view, these functions are useful (I have them defined myself), unambiguous, orthoganol (why have fromJust but not fromRight?) and something everyone wants at their fingertips. Just for the symetry of the library they should be kept in.
Actually, I'm starting to like the name unzipEithers, so I propose changing this patch to add only unzipEithers, lefts, and rights.
While those functions are useful, I use the ones you're dropping much much more... Thanks Neil
participants (9)
-
Bulat Ziganshin -
Conor McBride -
David House -
Henning Thielemann -
Neil Mitchell -
roconnor＠theorem.ca -
Ross Paterson -
Russell O'Connor
-
Samuel Bronson