Re: Libraries Digest, Vol 117, Issue 10
How about I just write a blog post teaching people how to use `for_` (and more generally, how to use `Maybe`'s `Foldable` instance)? I know Oliver Charles wrote a similar post in his 24 days of Hackage, and maybe I could build on that a bit more and perhaps make it as Google-able as possible so it comes up as the top result when people search for keywords like `whenJust` and other `Maybe` idioms. On Fri, May 10, 2013 at 11:25 AM, <libraries-request@haskell.org> wrote:
Send Libraries mailing list submissions to libraries@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to libraries-request@haskell.org
You can reach the person managing the list at libraries-owner@haskell.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."
Today's Topics:
1. Re: Control.Monad proposal: Add whenJust (Edward Kmett) 2. Re: Control.Monad proposal: Add whenJust (Evan Laforge) 3. Re: Control.Monad proposal: Add whenJust (Simon Hengel) 4. Re: Control.Monad proposal: Add whenJust (Andreas Abel) 5. Re: Control.Monad proposal: Add whenJust (Ivan Lazar Miljenovic) 6. Re: Control.Monad proposal: Add whenJust (Ganesh Sittampalam) 7. Re: Control.Monad proposal: Add whenJust (Petr Pudl?k)
----------------------------------------------------------------------
Message: 1 Date: Fri, 10 May 2013 07:16:53 -0400 From: Edward Kmett <ekmett@gmail.com> Subject: Re: Control.Monad proposal: Add whenJust To: Niklas Hamb?chen <mail@nh2.me> Cc: Haskell Libraries <libraries@haskell.org> Message-ID: < CAJumaK8XJrtdrXQfVb3pdi193ghz9ZEX8Q-MnVd435tDt5YFbg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
I'm -1 on this, due to it just further obfuscating the fact that Data.Foldable.for_ already exists.
On Fri, May 10, 2013 at 2:13 AM, Niklas Hamb?chen <mail@nh2.me> wrote:
I would like to propose the addition of
whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) f = f x whenJust _ _ = return ()
to Control.Monad, in the section
"Conditional execution of monadic expressions"
next to
guard :: MonadPlus m => Bool -> m () when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m ()
Why?
It would allow us to write more readable code and fit well into the group of similar functions of this style.
Compare
mUser <- lookupUser
whenJust mUser email
or
whenJust mUser $ \user -> do putStrLn "Mailing!" email user
with some currently available alternatives:
case mUser of Just user -> do putStrLn "Mailing!" email user Nothing -> return ()
(Default base case clutter.)
import Data.Foldable
forM_ mUser $ \user -> do putStrLn "Mailing!" email user
(Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.)
Some more dissatisfying alternatives:
maybe (return ()) (\user -> do putStrLn "Mailing!" email user ) mUser
flip (maybe (return ())) mUser $ \user -> do putStrLn "Mailing!" email user
import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift)
_ <- runMaybeT $ return mUser >>= \user -> lift $ do putStrLn "Mailing!" email user return ()
Alternative names:
- withJust, analog to withFile and withForeignPtr
Any comments?
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Perhaps we should have a dummy module in Hackage that includes commonly searched for functions, but instead of actually implementing them the documentation would say don't use this and suggest an alternative and explains why. Then you could find them in Hoogle and Hackage seems to be highly ranked on Google so they'd be found there as well. So a programmer would Google or Hoogle whenJust, find what they think is a module, take a look at the documentation, and find the alternative suggestion. Chris On 10 May 2013 11:44, Gabriel Gonzalez <gabriel439@gmail.com> wrote:
How about I just write a blog post teaching people how to use `for_` (and more generally, how to use `Maybe`'s `Foldable` instance)? I know Oliver Charles wrote a similar post in his 24 days of Hackage, and maybe I could build on that a bit more and perhaps make it as Google-able as possible so it comes up as the top result when people search for keywords like `whenJust` and other `Maybe` idioms.
On Fri, May 10, 2013 at 11:25 AM, <libraries-request@haskell.org> wrote:
Send Libraries mailing list submissions to libraries@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to libraries-request@haskell.org
You can reach the person managing the list at libraries-owner@haskell.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."
Today's Topics:
1. Re: Control.Monad proposal: Add whenJust (Edward Kmett) 2. Re: Control.Monad proposal: Add whenJust (Evan Laforge) 3. Re: Control.Monad proposal: Add whenJust (Simon Hengel) 4. Re: Control.Monad proposal: Add whenJust (Andreas Abel) 5. Re: Control.Monad proposal: Add whenJust (Ivan Lazar Miljenovic) 6. Re: Control.Monad proposal: Add whenJust (Ganesh Sittampalam) 7. Re: Control.Monad proposal: Add whenJust (Petr Pudl?k)
----------------------------------------------------------------------
Message: 1 Date: Fri, 10 May 2013 07:16:53 -0400 From: Edward Kmett <ekmett@gmail.com> Subject: Re: Control.Monad proposal: Add whenJust To: Niklas Hamb?chen <mail@nh2.me> Cc: Haskell Libraries <libraries@haskell.org> Message-ID: < CAJumaK8XJrtdrXQfVb3pdi193ghz9ZEX8Q-MnVd435tDt5YFbg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
I'm -1 on this, due to it just further obfuscating the fact that Data.Foldable.for_ already exists.
On Fri, May 10, 2013 at 2:13 AM, Niklas Hamb?chen <mail@nh2.me> wrote:
I would like to propose the addition of
whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) f = f x whenJust _ _ = return ()
to Control.Monad, in the section
"Conditional execution of monadic expressions"
next to
guard :: MonadPlus m => Bool -> m () when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m ()
Why?
It would allow us to write more readable code and fit well into the group of similar functions of this style.
Compare
mUser <- lookupUser
whenJust mUser email
or
whenJust mUser $ \user -> do putStrLn "Mailing!" email user
with some currently available alternatives:
case mUser of Just user -> do putStrLn "Mailing!" email user Nothing -> return ()
(Default base case clutter.)
import Data.Foldable
forM_ mUser $ \user -> do putStrLn "Mailing!" email user
(Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.)
Some more dissatisfying alternatives:
maybe (return ()) (\user -> do putStrLn "Mailing!" email user ) mUser
flip (maybe (return ())) mUser $ \user -> do putStrLn "Mailing!" email user
import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift)
_ <- runMaybeT $ return mUser >>= \user -> lift $ do putStrLn "Mailing!" email user return ()
Alternative names:
- withJust, analog to withFile and withForeignPtr
Any comments?
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Fri, May 10, 2013 at 2:54 PM, Chris Seaton <chris@chrisseaton.com> wrote:
Perhaps we should have a dummy module in Hackage that includes commonly searched for functions, but instead of actually implementing them the documentation would say don't use this and suggest an alternative and explains why. Then you could find them in Hoogle and Hackage seems to be highly ranked on Google so they'd be found there as well.
Or expand hlint to catch whenJust like constructs and suggest use of the alternative? We already did that for when 'void' was added, put in a suggestion looking for things like '>> return ()' -- gwern http://www.gwern.net
IMNSHO, I think we should just add -- | @whenJust = 'for_'@. Executes the given action -- when @Just@, execute nothing if @Nothing@. whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust = for_ to Data.Maybe. Even if it's duplicating a functionality, it's a good name that has been reinvented by many people. Its docs may mention for_ and teach the user that for_ is more generic etc. People looking for whenJust *will* look at Data.Maybe. We don't lose much by adding this function. On Fri, May 10, 2013 at 4:00 PM, Gwern Branwen <gwern@gwern.net> wrote:
On Fri, May 10, 2013 at 2:54 PM, Chris Seaton <chris@chrisseaton.com> wrote:
Perhaps we should have a dummy module in Hackage that includes commonly searched for functions, but instead of actually implementing them the documentation would say don't use this and suggest an alternative and explains why. Then you could find them in Hoogle and Hackage seems to be highly ranked on Google so they'd be found there as well.
Or expand hlint to catch whenJust like constructs and suggest use of the alternative? We already did that for when 'void' was added, put in a suggestion looking for things like '>> return ()'
-- gwern http://www.gwern.net
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
On 10.05.13 9:30 PM, Felipe Almeida Lessa wrote:
IMNSHO, I think we should just add
-- | @whenJust = 'for_'@. Executes the given action -- when @Just@, execute nothing if @Nothing@. whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust = for_
to Data.Maybe. Even if it's duplicating a functionality, it's a good name that has been reinvented by many people. Its docs may mention for_ and teach the user that for_ is more generic etc. People looking for whenJust *will* look at Data.Maybe. We don't lose much by adding this function.
+1. whenJust seems to be canonical and is reinvented again and again. We can add it now or have the next discussion in 6 month or a year. Previous discussions: June 2009: http://www.haskell.org/pipermail/libraries/2009-June/011836.html Nov 2011: http://haskell.1045720.n5.nabble.com/Proposal-add-Control-Monad-whenJust-Mon... Dec 2012: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/18519 See also Felipe's post at: https://groups.google.com/forum/?fromgroups=#!topic/haskell-cafe/aWtC8DRfGYs Cheers, Andreas
On Fri, May 10, 2013 at 4:00 PM, Gwern Branwen <gwern@gwern.net> wrote:
On Fri, May 10, 2013 at 2:54 PM, Chris Seaton <chris@chrisseaton.com> wrote:
Perhaps we should have a dummy module in Hackage that includes commonly searched for functions, but instead of actually implementing them the documentation would say don't use this and suggest an alternative and explains why. Then you could find them in Hoogle and Hackage seems to be highly ranked on Google so they'd be found there as well.
Or expand hlint to catch whenJust like constructs and suggest use of the alternative? We already did that for when 'void' was added, put in a suggestion looking for things like '>> return ()'
-- gwern http://www.gwern.net
-- 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 Fri, May 10, 2013 at 5:04 PM, Andreas Abel <andreas.abel@ifi.lmu.de> wrote:
See also Felipe's post at: https://groups.google.com/forum/?fromgroups=#!topic/haskell-cafe/aWtC8DRfGYs
Yup! There have been so many rediscoveries that I even rediscovered it twice ;). -- Felipe.
Am 10.05.2013 21:00, schrieb Gwern Branwen:
Or expand hlint to catch whenJust like constructs and suggest use of the alternative? We already did that for when 'void' was added, put in a suggestion looking for things like '>> return ()'
I have suggested such rules to Neil Mitchell but he hesitated to recommend functions from Data.Foldable module.
On Sat, May 11, 2013 at 01:10:10AM +0200, Henning Thielemann wrote:
I have suggested such rules to Neil Mitchell but he hesitated to recommend functions from Data.Foldable module.
Maybe what we really need to do is work out why Data.Foldable is so maligned, and sort out the import conflicts so it's easier to use. I think with the lists-of-length-at-most-1 metaphor, using for_ with Maybe is perfectly logical (if you like, imagine an implicit maybeToList in there).
On Sat, May 11, 2013 at 06:15:53PM +0100, Ben Millwood wrote:
On Sat, May 11, 2013 at 01:10:10AM +0200, Henning Thielemann wrote:
I have suggested such rules to Neil Mitchell but he hesitated to recommend functions from Data.Foldable module.
Maybe what we really need to do is work out why Data.Foldable is so maligned, and sort out the import conflicts so it's easier to use.
Yes, sorting out the import conflicts would be awesome.
I think with the lists-of-length-at-most-1 metaphor, using for_ with Maybe is perfectly logical (if you like, imagine an implicit maybeToList in there).
Yes, exactly.
On Sat, 11 May 2013, Simon Hengel wrote:
On Sat, May 11, 2013 at 06:15:53PM +0100, Ben Millwood wrote:
Maybe what we really need to do is work out why Data.Foldable is so maligned, and sort out the import conflicts so it's easier to use.
Yes, sorting out the import conflicts would be awesome.
There are no import conflicts if you import properly ...
Importing "properly" is no small problem. Look at nikki&robots source code for example, some modules there have 200 imports. Even if you use an Import module to shorten your import list, some things still want to be imported qualified. Then you're left with the choice of either using something like classy-prelude, or pulling in a preprocessor to manage your imports. On Sun, 12 May 2013 02:58:29 +0200 (CEST) Henning Thielemann <lemming@henning-thielemann.de> wrote:
On Sat, 11 May 2013, Simon Hengel wrote:
On Sat, May 11, 2013 at 06:15:53PM +0100, Ben Millwood wrote:
Maybe what we really need to do is work out why Data.Foldable is so maligned, and sort out the import conflicts so it's easier to use.
Yes, sorting out the import conflicts would be awesome.
There are no import conflicts if you import properly ...
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Sun, May 12, 2013 at 02:58:29AM +0200, Henning Thielemann wrote:
On Sat, 11 May 2013, Simon Hengel wrote:
On Sat, May 11, 2013 at 06:15:53PM +0100, Ben Millwood wrote:
Maybe what we really need to do is work out why Data.Foldable is so maligned, and sort out the import conflicts so it's easier to use.
Yes, sorting out the import conflicts would be awesome.
There are no import conflicts if you import properly ...
That has its own problems – if every substantial patch involves touching the import list, your patches don't merge. If instead of explicit import lists you use qualification, then everyone names the module themselves (no-one wants to write Data.Foldable) and possibly names it different things (my habit is initial letters, until I need to import Data.Text and Data.Traversable...) You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
On Sun, 12 May 2013, Ben Millwood wrote:
If instead of explicit import lists you use qualification, then everyone names the module themselves (no-one wants to write Data.Foldable) and possibly names it different things (my habit is initial letters, until I need to import Data.Text and Data.Traversable...)
I define function names that make sense when being qualified with the module name. This way I do not need one-letter abbreviations when importing a module. I think a function name like Text.fromString is both more readable than T.pack and will not clash with Traversable.
* Ben Millwood <haskell@benmachine.co.uk> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :) Roman
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point. I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it. -Edward On Wed, May 15, 2013 at 10:25 AM, Ben Millwood <haskell@benmachine.co.uk>wrote:
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
+1 What would be the best way to do this? 1) Immediately remove all monomorphic versions and export the Foldable and Traversable versions instead. I can imagine this can introduce type ambiguity errors. 2) First deprecate the monomorphic versions in favor of the versions from Data.Foldable and Data.Traversable. This gives users a warning that they need to update their code. But to get rid of the warning they have to import from Data.Foldable or Data.Traversable (the have to use qualified imports or hide the deprecated functions from the Prelude). Then in a later version of base the monomorphic versions are removed and the Foldable and Traversable versions are exported instead. At this point the users may want to update their code again to just import the functions from the Prelude to reduce the number of imports. 3) Some process I have not thought about yet... Currently, I would favor 1 since I expect the breakage to be minimal. Bas
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude. It seems odd to me that some functions (e.g. mapM) are implicitly available, while for others (forM, mapAccumL, etc) you need an import. It would make more sense to me to move towards a situation where nothing (or at least, much less) is in scope by default. If taken to extremes, interactive environments like ghci might choose to have more things in scope by default. Thanks Ian
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable)
into the
Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude. I did say when I made the suggestion that I didn't think it'd make it past the objections, though. I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general. 5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable. 3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude. And 2 votes against doing anything. At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win. -Edward On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com> wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable)
into the
Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
i'm not even sure if i'm allowed to vote on proposals, having spent some time on the wiki trying to find out. also it seems i'm a few hours too late, but i feel it would be a shame for this proposal to die. i'm personally agnostic between the two positive proposals but i'll vote for the first one (fixing the Prelude) if that's what it takes to get plurality. so, if my vote counts for anything, +1 "for just fixing the Prelude to swap in the definitions from Foldable and Traversable." best, ben On May 19, 2013, at 9:33 AM, Edward Kmett wrote:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com> wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Another +1, specifically on swapping in definitions from Foldable and Traversable. To address the concern of "more trouble for beginners," it's important to note that lots of functions are defined differently in the prelude than how they're explained in intro texts. Haskell's becoming a language with excellent support for many different collection types, and imo it's almost old-fashioned to have so much in base defined as if lists are of much greater importance. Tom El May 19, 2013, a las 12:33 PM, Edward Kmett <ekmett@gmail.com> escribió:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com> wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Do the additional votes on foldable / traversable change the outcome? On Sunday, May 19, 2013, Edward Kmett wrote:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com<javascript:_e({}, 'cvml', 'jwlato@gmail.com');>
wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com<javascript:_e({}, 'cvml', 'ian@well-typed.com');>> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com<javascript:_e({}, 'cvml', 'ekmett@gmail.com');>>
wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/mailman/listinfo/libraries
Well, it so far has definitely put the preponderance of weight of opinion on just replacing the definitions in the Prelude with Foldable and Traversable definitions. I do think we should probably move it to another topic, as we're definitely not talking about whenJust. (In particular a +1 on this stuff is effectively a -1 on the original topic!) On Sun, May 19, 2013 at 7:00 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
Do the additional votes on foldable / traversable change the outcome?
On Sunday, May 19, 2013, Edward Kmett wrote:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com> wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable)
into the
Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On May 19, 2013, at 10:33 AM, Edward Kmett <ekmett@gmail.com> wrote:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result. Anthony
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com> wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Good idea, though each channel / fora seems to have slightly disjoint sub communities. On Sunday, May 19, 2013, Anthony Cowley wrote:
On May 19, 2013, at 10:33 AM, Edward Kmett <ekmett@gmail.com<javascript:_e({}, 'cvml', 'ekmett@gmail.com');>> wrote:
The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude.
I did say when I made the suggestion that I didn't think it'd make it past the objections, though.
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
Anthony
I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general.
5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable.
3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude.
And 2 votes against doing anything.
At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly retract the proposal and let the vocal 20% win.
-Edward
On Sat, May 18, 2013 at 8:02 PM, John Lato <jwlato@gmail.com<javascript:_e({}, 'cvml', 'jwlato@gmail.com');>
wrote:
On May 18, 2013 10:09 PM, "Ian Lynagh" <ian@well-typed.com<javascript:_e({}, 'cvml', 'ian@well-typed.com');>> wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com<javascript:_e({}, 'cvml', 'ekmett@gmail.com');>>
wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1 to Ian's suggestion.
_______________________________________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/mailman/listinfo/libraries
On Sun, 19 May 2013, Anthony Cowley wrote:
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
I also consider the proposal to be a pretty big thing. I am not sure that all people who are affected are aware of this discussion, especially since it happens under the subject "add whenJust". Changing the Prelude was only done for 'catch' as far as I remember. Moving Traversable and Foldable to Prelude is for me a precedent. It has more implications: I think it must also go into the Haskell 201x specification. It would mean that Traversable and Foldable are immediately in scope in every module. And what is the long-term goal? Shall Prelude contain all classes, that generalize Prelude's types? Applicative? Category? Monoid? MonadPlus? Semigroup? If you think this out, you may want not to do the first step in this direction. The reason for the proposal is really only to save writing some "import" statements for people who prefer the unqualified import style, right? I still think it is much simpler to achieve this by putting more effort in alternative Prelude projects.
Maybe instead of fiddling with the current Prelude (which might break backwards compatibility), we should design a new prelude which is not automatically loaded but contains roughly the current prelude (with the list functions generalized to collections) plus the "modern" type class stack: Functor, Applicative, Monad, Foldable, Traversable, Monoid etc. I am willing to write {-# LANGUAGE NoImplicitPrelude #-} import Base if I get a decent, "modern" standard set of functions that could be considered as the base vocabulary of modern Haskell programmers... I just do not want to think about the democratic process involved in this design... Cheers, Andreas On 20.05.13 9:35 AM, Henning Thielemann wrote:
On Sun, 19 May 2013, Anthony Cowley wrote:
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
I also consider the proposal to be a pretty big thing. I am not sure that all people who are affected are aware of this discussion, especially since it happens under the subject "add whenJust". Changing the Prelude was only done for 'catch' as far as I remember. Moving Traversable and Foldable to Prelude is for me a precedent. It has more implications: I think it must also go into the Haskell 201x specification. It would mean that Traversable and Foldable are immediately in scope in every module. And what is the long-term goal? Shall Prelude contain all classes, that generalize Prelude's types? Applicative? Category? Monoid? MonadPlus? Semigroup? If you think this out, you may want not to do the first step in this direction.
The reason for the proposal is really only to save writing some "import" statements for people who prefer the unqualified import style, right? I still think it is much simpler to achieve this by putting more effort in alternative Prelude projects.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- 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 Mon, 20 May 2013, Andreas Abel wrote:
Maybe instead of fiddling with the current Prelude (which might break backwards compatibility), we should design a new prelude which is not automatically loaded but contains roughly the current prelude (with the list functions generalized to collections) plus the "modern" type class stack: Functor, Applicative, Monad, Foldable, Traversable, Monoid etc.
I think the Hackage category Prelude gives a good overview over such projects: http://hackage.haskell.org/package/#cat:prelude
On 5/19/13 7:25 PM, Anthony Cowley wrote:
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
Indeed. Personally, I'm all for blessing Foldable/Traversable as "built-in" and getting rid of the monomorphic legacy. But then, I'm also all for making Applicative a superclass of Monad, not having all the mtl modules re-export everything from Control.Monad, etc. However, all of these issues have a long history of discord, and that discord cannot be resolved on this list IMO. I'm generally a staunch advocate of backward compatibility. However, these issues are ones where we've known the right answer for a long time (unlike refactoring the numeric type class hierarchy), and we've simply been unwilling to burn bridges in order to do the right thing. I love Haskell, and I respect the haskell' committee, but I think it's time to just burn it all down. Let us not forget the original reasons for many of these warts. Some of them stem from ignorance or oversight (superclasses of Monad); others stem from the desire to help newcomers (monomorphism); and others stem from circularities in the language definition (the existence of the Prelude). As Haskell has developed, we have learned more ---therefore we should not embrace prior ignorance---, our standard idioms have evolved ---therefore clinging to list-monomorphism *causes* confusion rather than alleviating it---, and we've tried to remove much of the circularity involved in desugaring the various built-in notations for lists, arithmetic sequences, do-notation, etc. With all that has changed in the last 15 years, I think it's high time to fork Haskell, tear off all the bandaids, and begin afresh. This won't solve all the problems, of course. We will still despair of the numeric hierarchy; we will still despair of the partial functions demanded by the Haskell spec; we will still worry about how to resolve things like MPTCs, type families, and all that. But at least we can finally put these particular ghosts to rest. Alas, to fork the language is to split the community. And while I advocate such drastic measures, they are measures which cannot be resolved either on this list or by the (intentionally conservative) haskell' committee. -- Live well, ~wren
IMHO, the problem is that the community isn't large enough to be able to suffer a split. Case in point: how are we going to have two GHC HQs? If we're going to burn bridges, perhaps we should follow a Python-3-esque path of releasing a major upgrade together with: - A refactoring tool to aid with the transition. - A deadline of, say, 2-3 years during which the latest GHC for current Haskell would receive bugfixes while GHC 8 moves along as usual. Cheers, On Mon, May 20, 2013 at 7:49 PM, wren ng thornton <wren@freegeek.org> wrote:
On 5/19/13 7:25 PM, Anthony Cowley wrote:
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
Indeed.
Personally, I'm all for blessing Foldable/Traversable as "built-in" and getting rid of the monomorphic legacy. But then, I'm also all for making Applicative a superclass of Monad, not having all the mtl modules re-export everything from Control.Monad, etc. However, all of these issues have a long history of discord, and that discord cannot be resolved on this list IMO.
I'm generally a staunch advocate of backward compatibility. However, these issues are ones where we've known the right answer for a long time (unlike refactoring the numeric type class hierarchy), and we've simply been unwilling to burn bridges in order to do the right thing. I love Haskell, and I respect the haskell' committee, but I think it's time to just burn it all down.
Let us not forget the original reasons for many of these warts. Some of them stem from ignorance or oversight (superclasses of Monad); others stem from the desire to help newcomers (monomorphism); and others stem from circularities in the language definition (the existence of the Prelude). As Haskell has developed, we have learned more ---therefore we should not embrace prior ignorance---, our standard idioms have evolved ---therefore clinging to list-monomorphism *causes* confusion rather than alleviating it---, and we've tried to remove much of the circularity involved in desugaring the various built-in notations for lists, arithmetic sequences, do-notation, etc.
With all that has changed in the last 15 years, I think it's high time to fork Haskell, tear off all the bandaids, and begin afresh. This won't solve all the problems, of course. We will still despair of the numeric hierarchy; we will still despair of the partial functions demanded by the Haskell spec; we will still worry about how to resolve things like MPTCs, type families, and all that. But at least we can finally put these particular ghosts to rest. Alas, to fork the language is to split the community. And while I advocate such drastic measures, they are measures which cannot be resolved either on this list or by the (intentionally conservative) haskell' committee.
-- Live well, ~wren
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
On 5/20/13 6:59 PM, Felipe Almeida Lessa wrote:
IMHO, the problem is that the community isn't large enough to be able to suffer a split.
That is indeed the problem. Which is why we've argued about it forever without making any progress, IMO.
If we're going to burn bridges, perhaps we should follow a Python-3-esque path of releasing a major upgrade together with:
- A refactoring tool to aid with the transition.
- A deadline of, say, 2-3 years during which the latest GHC for current Haskell would receive bugfixes while GHC 8 moves along as usual.
That's actually what I had in mind, rather than a true (parallel) fork. Just an official jump from Haskell-1 to Haskell-2, with no claims of compatibility between the two. Of course, if we are going to do this, I think it'd be good to make the decision official and then take a year or so to work out the full details. That is, if we're going to break everything, we should make sure we don't overlook any of the low-hanging fruit[1]. Given the recent turnover for the haskell' committee, it'd be good to talk to them too. Even with a big jump, I think it'd be good to aim for conservatism; that is, the goal is to remove all the major warts, not to solve any deep problems. [1] One that has been bothering me recently is the requirement that methods of Enum are partial functions. I have a proposal for fixing this and generalizing enumeration, which I'll post as a package later this week. -- Live well, ~wren
Whoa! I don't think that replacing list-monomorphic functions in the prelude with more-general ones is going to cause the community to split down the middle! Most of the changes we're talking about won't even break any legacy code! Of course, some typeclass-rearranging will break things, but not the prelude replacements that we've been discussing. The biggest impact is that existing teaching texts may have old information about the type signatures of standard functions. As much as I *love* imagining the Haskell community in a bridge-burning, rival GHC HQ deathmatch (Simon vs. Simon! Edward vs. Edward!), I really think this change won't attract the interest of any tabloids. That said, I definitely agree that it should take more than a few +1s to move this forward. I'd suggest a relative-consensus on the libraries list, then a "Here's our plan; are we crazy?" email on haskell-cafe. Tom El May 20, 2013, a las 6:59 PM, Felipe Almeida Lessa <felipe.lessa@gmail.com> escribió:
IMHO, the problem is that the community isn't large enough to be able to suffer a split. Case in point: how are we going to have two GHC HQs?
If we're going to burn bridges, perhaps we should follow a Python-3-esque path of releasing a major upgrade together with:
- A refactoring tool to aid with the transition.
- A deadline of, say, 2-3 years during which the latest GHC for current Haskell would receive bugfixes while GHC 8 moves along as usual.
Cheers,
On Mon, May 20, 2013 at 7:49 PM, wren ng thornton <wren@freegeek.org> wrote:
On 5/19/13 7:25 PM, Anthony Cowley wrote:
I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result.
Indeed.
Personally, I'm all for blessing Foldable/Traversable as "built-in" and getting rid of the monomorphic legacy. But then, I'm also all for making Applicative a superclass of Monad, not having all the mtl modules re-export everything from Control.Monad, etc. However, all of these issues have a long history of discord, and that discord cannot be resolved on this list IMO.
I'm generally a staunch advocate of backward compatibility. However, these issues are ones where we've known the right answer for a long time (unlike refactoring the numeric type class hierarchy), and we've simply been unwilling to burn bridges in order to do the right thing. I love Haskell, and I respect the haskell' committee, but I think it's time to just burn it all down.
Let us not forget the original reasons for many of these warts. Some of them stem from ignorance or oversight (superclasses of Monad); others stem from the desire to help newcomers (monomorphism); and others stem from circularities in the language definition (the existence of the Prelude). As Haskell has developed, we have learned more ---therefore we should not embrace prior ignorance---, our standard idioms have evolved ---therefore clinging to list-monomorphism *causes* confusion rather than alleviating it---, and we've tried to remove much of the circularity involved in desugaring the various built-in notations for lists, arithmetic sequences, do-notation, etc.
With all that has changed in the last 15 years, I think it's high time to fork Haskell, tear off all the bandaids, and begin afresh. This won't solve all the problems, of course. We will still despair of the numeric hierarchy; we will still despair of the partial functions demanded by the Haskell spec; we will still worry about how to resolve things like MPTCs, type families, and all that. But at least we can finally put these particular ghosts to rest. Alas, to fork the language is to split the community. And while I advocate such drastic measures, they are measures which cannot be resolved either on this list or by the (intentionally conservative) haskell' committee.
-- Live well, ~wren
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
| I'm generally a staunch advocate of backward compatibility. However, | these issues are ones where we've known the right answer for a long time | (unlike refactoring the numeric type class hierarchy), and we've simply | been unwilling to burn bridges in order to do the right thing. I love | Haskell, and I respect the haskell' committee, but I think it's time to | just burn it all down. ... | With all that has changed in the last 15 years, I think it's high time | to fork Haskell, tear off all the bandaids, and begin afresh. I'm not sure what you are proposing, concrete, by "fork Haskell". I think you are simply proposing some non-backward compatible library changes. Correct? And yes, it seems reasonable to do that every now and again. Indeed there's an active thread on splitting the base package http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it easier to build a backward-compatible shim package. So how non-backward-compatible would it all be? I assume you guys have talked this to death, but is there no way to move on, while leaving a backward-compatible API? Simon
I raised the issue mostly to remind everyone that it still existed and that the status quo is quite awkward. I was going to let this rest, but as it seems to still be stirring up a passionate response, I felt it necessary to reply again. I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change. During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now. Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have *base* only contain one version of each combinator that it exports. The combinators in Data.Foldable and Data.Traversable simply subsume all of the other redundant versions of them that occur in base. Sure there are reasons why other libraries have chosen to replicate large portions of the API from Base for particular data types with particular constraints, but those are just that -- other libraries. Moreover, if Applicative can ever be made a superclass of Monad, half of the combinators in can Data.Traversable melt away and so can several of the ones in Data.Foldable, reducing the footprint further. I tend to disagree with Ian that mapM, etc. should simply be removed from the Prelude completely. Foldable and Traversable -- unlike almost everything being debated to death in the base split -- aren't things that require heavy machinery. There are no exceptions in them, nothing that is difficult to implement across platforms or compilers. The sum total of language support for them is the DeriveFoldable and DeriveTraversable extensions. They are also quite ingrained in the 'culture' of Haskell. I for one would hate to lose them from the vocabulary of the Prelude. -Edward On Tue, May 21, 2013 at 2:22 AM, Simon Peyton-Jones <simonpj@microsoft.com>wrote:
| I'm generally a staunch advocate of backward compatibility. However, | these issues are ones where we've known the right answer for a long time | (unlike refactoring the numeric type class hierarchy), and we've simply | been unwilling to burn bridges in order to do the right thing. I love | Haskell, and I respect the haskell' committee, but I think it's time to | just burn it all down. ... | With all that has changed in the last 15 years, I think it's high time | to fork Haskell, tear off all the bandaids, and begin afresh.
I'm not sure what you are proposing, concrete, by "fork Haskell".
I think you are simply proposing some non-backward compatible library changes. Correct? And yes, it seems reasonable to do that every now and again. Indeed there's an active thread on splitting the base package http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it easier to build a backward-compatible shim package. So how non-backward-compatible would it all be?
I assume you guys have talked this to death, but is there no way to move on, while leaving a backward-compatible API?
Simon
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
well said, On Tue, May 21, 2013 at 2:57 AM, Edward Kmett <ekmett@gmail.com> wrote:
I raised the issue mostly to remind everyone that it still existed and that the status quo is quite awkward. I was going to let this rest, but as it seems to still be stirring up a passionate response, I felt it necessary to reply again.
I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change.
During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now.
Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have *base* only contain one version of each combinator that it exports.
The combinators in Data.Foldable and Data.Traversable simply subsume all of the other redundant versions of them that occur in base.
Sure there are reasons why other libraries have chosen to replicate large portions of the API from Base for particular data types with particular constraints, but those are just that -- other libraries.
Moreover, if Applicative can ever be made a superclass of Monad, half of the combinators in can Data.Traversable melt away and so can several of the ones in Data.Foldable, reducing the footprint further.
I tend to disagree with Ian that mapM, etc. should simply be removed from the Prelude completely. Foldable and Traversable -- unlike almost everything being debated to death in the base split -- aren't things that require heavy machinery. There are no exceptions in them, nothing that is difficult to implement across platforms or compilers. The sum total of language support for them is the DeriveFoldable and DeriveTraversable extensions. They are also quite ingrained in the 'culture' of Haskell.
I for one would hate to lose them from the vocabulary of the Prelude.
-Edward
On Tue, May 21, 2013 at 2:22 AM, Simon Peyton-Jones <simonpj@microsoft.com
wrote:
| I'm generally a staunch advocate of backward compatibility. However, | these issues are ones where we've known the right answer for a long time | (unlike refactoring the numeric type class hierarchy), and we've simply | been unwilling to burn bridges in order to do the right thing. I love | Haskell, and I respect the haskell' committee, but I think it's time to | just burn it all down. ... | With all that has changed in the last 15 years, I think it's high time | to fork Haskell, tear off all the bandaids, and begin afresh.
I'm not sure what you are proposing, concrete, by "fork Haskell".
I think you are simply proposing some non-backward compatible library changes. Correct? And yes, it seems reasonable to do that every now and again. Indeed there's an active thread on splitting the base package http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it easier to build a backward-compatible shim package. So how non-backward-compatible would it all be?
I assume you guys have talked this to death, but is there no way to move on, while leaving a backward-compatible API?
Simon
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change.
During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now.
I agree with those points, however they are a little (for the lack of a better word) single-cased, therefore I'm not sure how well they transfer to new scenarios. The catch/Num transitions are on a much smaller scale than what has been discussed here after all. I think the main issue we'll have to address here is inertia, more specifically how much more people value inertia over the proposed changes, no matter how good they are. I'm just going to throw this idea out there: what would you think about adding warnings to GHC specifically for the transition, think of meta-deprecations? Examples: - Use the (more) polymorphic functions from Foldable/Traversable - Please also define Functor/Applicative for your Monad Potential benefits: - During the GHCi-based workflow that I use, as I am sure many others do, this would help me not to forget or ignore doing these things. Sometimes it may be more convenient just to take what Prelude gives me (call it the "whatever, it works for now" attitude), but when a warning is nagging me I'll think "alright, it's for the greater good™ so I'll add the import". - GHC's ability to point the user to the location of an error is quite amazing. Equipped with this, fixing other (possibly unmaintained) modules would probably by very easy. - -fno-transitional-warnings could disable these messages for a warning-free build I realize adding this may be a bit hacky, as GHC knows nothing about Applicative/Foldable/..., so the warnings will be hardcoded. However, I would consider this a transitional implementation detail far outweighed by its benefits. David PS: I'm aware this is (again) a post that arguably belongs to the ghc-dev list, but I think it goes well with this discussion.
On Tue, May 21, 2013 at 2:57 AM, Edward Kmett <ekmett@gmail.com> wrote:
Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have base only contain one version of each combinator that it exports.
I would be interested to see a real example of existing code of anywhere near production quality that would break due to type inference issues. For breakage to happen, the combinators must be used in such a way that [] cannot be inferred by other means and an appropriate Foldable/Traversable constraint cannot simply be inferred instead. Neither class provides a means for constructing values of an instance type ex nihilo and lacking anything like an Unfoldable class the "show . read" situation is unlikely. Anything applied to a list will be inferred in the usual manner. Definitions with no type signature, subject to the DMR, and not used in the module that defines them should be excluded by "anywhere near production quality". Short of folding a list which was constructed entirely by way of MonadPlus or similar I can't see where problems would arise. Am I missing something here? Beyond that, the argument that having redundant, less-polymorphic versions of standard combinators is helping beginners has not become any less ridiculous since the first time I heard it. These beginners still have to cope with typos that lead to GHC suggesting nonsense such as writing a Num instance for "[Char] -> a2", while on the other hand unnecessary duplication and redundancy absolutely cause problems. On more than one occasion I've explained to a beginner confused by the difference between map and fmap that the sole reason they differ is to avoid confusing beginners. Doubleplus ungood, my friends.
Moreover, if Applicative can ever be made a superclass of Monad, half of the combinators in can Data.Traversable melt away and so can several of the ones in Data.Foldable, reducing the footprint further.
Which would be a fantastic improvement in multiple ways.
I tend to disagree with Ian that mapM, etc. should simply be removed from the Prelude completely. Foldable and Traversable -- unlike almost everything being debated to death in the base split -- aren't things that require heavy machinery. There are no exceptions in them, nothing that is difficult to implement across platforms or compilers. The sum total of language support for them is the DeriveFoldable and DeriveTraversable extensions. They are also quite ingrained in the 'culture' of Haskell.
Those combinators (or the unnecessarily monomorphic counterparts thereof) are also often used unqualified in code such as nearly all of it, found in packages such as nearly all of them. If we're going to remove mapM &c. from Prelude and thereby break everything everywhere, we should at least do something useful along with it, like replace the entire hierarchy of numeric classes.
I for one would hate to lose them from the vocabulary of the Prelude.
I would hate to see the common vocabulary of Haskell code reduced. Let's not invite the Tower of Babel scenario (any more than we already do) where everyone has their own preferred set of libraries for common tasks with no useful, mutually intelligible intersection between them. For all its problems, the current Prelude at least provides a decent foundation for accomplishing common tasks. - C.
Casey McCann <cam@uptoisomorphism.net> writes:
Beyond that, the argument that having redundant, less-polymorphic versions of standard combinators is helping beginners has not become any less ridiculous since the first time I heard it.
As I sit here in agreement with Edward, and comments like Casey's above, I begin to wonder: does the assumed minority who opposes such changes even exist anymore? Is there a chance we've fallen into the trap of assuming that they exist, and so shying away from formally proposing changes like this one? For example, in personal discussions, on IRC, and on the mailing lists, I see a resounding consensus that Applicative should become a superclass of Monad -- and that we can fix the breakages that will result. I also see consensus towards a less monomorphic Prelude (which dovetails nicely with the aforementioned Applicative change, as Edward explained). Why should the few (if they are even still out there!) who do not want such changes be allowed to rule the day? Why do I hear so many voices raised up in agreement, and then silenced by comparatively little opposition? If "avoiding success at all costs" is jokingly our by-word, are not backwards incompatible changes in the name of seeking perfection one of the best ways to forestall success? :) -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net
On Wed, May 22, 2013 at 8:18 AM, John Wiegley <johnw@fpcomplete.com> wrote:
Casey McCann <cam@uptoisomorphism.net> writes:
Beyond that, the argument that having redundant, less-polymorphic versions of standard combinators is helping beginners has not become any less ridiculous since the first time I heard it.
As I sit here in agreement with Edward, and comments like Casey's above, I begin to wonder: does the assumed minority who opposes such changes even exist anymore? Is there a chance we've fallen into the trap of assuming that they exist, and so shying away from formally proposing changes like this one?
The proposal should continue to come up until there are no objections. In all seriousness, there's a hydra of threads about a bunch of quasi-related issues, and much debate has happened since the last time I saw a vote tally. There's a lot of confusion, and doubtless some people have chosen to stay out completely. I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1. Debate can continue in one of the other threads if necessary, but this will make it very easy to see exactly where the community stands. John L.
+1 On Wed, May 22, 2013 at 3:40 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2013-05-22 05:49:29 +0200, John Lato wrote:
[...]
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
+1
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 On Wed, May 22, 2013 at 3:52 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
+1
On Wed, May 22, 2013 at 3:40 AM, Herbert Valerio Riedel <hvr@gnu.org>wrote:
On 2013-05-22 05:49:29 +0200, John Lato wrote:
[...]
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
+1
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
This is slightly confusing. Are those "+1"s for the original proposal or for starting a poll? Counting email responses seems to be cumbersome, what about using some kind of public web service for this? We'd see all the results at one place. I haven't used anything like that before, but Google showed many such webapps: micropoll.com, easypolls.net, ... Best regards, Petr Dne 05/22/2013 11:47 AM, Edward Kmett napsal(a):
+1
On Wed, May 22, 2013 at 3:52 AM, Carter Schonwald <carter.schonwald@gmail.com <mailto:carter.schonwald@gmail.com>> wrote:
+1
On Wed, May 22, 2013 at 3:40 AM, Herbert Valerio Riedel <hvr@gnu.org <mailto:hvr@gnu.org>> wrote:
On 2013-05-22 05:49:29 +0200, John Lato wrote:
[...]
> I suggest that we start a poll for a single, concrete proposal. If the > poll forum is by email or similar, I further suggest that replies be > limited strictly to +1/-1.
+1
_______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
2013/5/22 John Lato <jwlato@gmail.com>:
a vote tally. There's a lot of confusion, and doubtless some people have chosen to stay out completely.
I am such person. Mainly because even if I would like some proposal to move forward, I don't feel like I'm entitled to vote on it (I've never uploaded anything to hackage, for example, and I might not be knowledgeable enough that my vote should count.) So I was wondering what is the etiquette on voting, but I couldn't find an answer. I admit I only looked at the Mailing_Lists page on the wiki, and made a couple of google searches. David.
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc * Remove Prelude.mapM etc * Add more monomorphic variants to Prelude (e.g. whenJust) * Nothing If we're going to have a poll, then I think it should allow people to rank all the options. +1/-1 ona single option would only give a sense of whether an option is prefered to doing nothing, not whether it is the best option. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1 Tom
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing On 2013-05-22 16:59, Dan Doel wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing
On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com <mailto:ekmett@gmail.com>> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com <mailto:amindfv@gmail.com>> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com <mailto:ian@well-typed.com>> escribió:
> On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote: >> >> I suggest that we start a poll for a single, concrete proposal. If the >> poll forum is by email or similar, I further suggest that replies be >> limited strictly to +1/-1. > > I think there are 4 things it has been suiggested that we might do: > * Generalise Prelude.mapM etc
+1
> * Remove Prelude.mapM etc
-1
> * Add more monomorphic variants to Prelude (e.g. whenJust)
0
> * Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 -1 -1 -1 On May 22, 2013 10:25 AM, "Edward Kmett" <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 for generalization -1 for removal -1 for adding more monomorphic stuff to Prelude -1 for doing nothing On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing On Wed, May 22, 2013 at 1:57 PM, Casey McCann <cam@uptoisomorphism.net> wrote:
+1 for generalization -1 for removal -1 for adding more monomorphic stuff to Prelude -1 for doing nothing
On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing On May 22, 2013, at 11:05 AM, Felipe Almeida Lessa <felipe.lessa@gmail.com> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing
On Wed, May 22, 2013 at 1:57 PM, Casey McCann <cam@uptoisomorphism.net> wrote:
+1 for generalization -1 for removal -1 for adding more monomorphic stuff to Prelude -1 for doing nothing
On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 generalize prelude +1 remove from prelude -1 add more monomorphic stuff -1 do nothing On May 22, 2013, at 10:05 AM, Felipe Almeida Lessa wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing
On Wed, May 22, 2013 at 1:57 PM, Casey McCann <cam@uptoisomorphism.net> wrote:
+1 for generalization -1 for removal -1 for adding more monomorphic stuff to Prelude -1 for doing nothing
On Wed, May 22, 2013 at 10:23 AM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Felipe.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett <ekmett@gmail.com> writes:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
+1 -1 -1 -1 -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing You are all nuts. :-) Regards, Malcolm. On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing Cheers. On Wed, May 22, 2013 at 11:32 PM, Malcolm Wallace <malcolm.wallace@me.com>wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
Regards, Malcolm.
On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
FWIW, my opinion would be +1 Remove from Prelude 0 Generalize Prelude 0 Do nothing -1 Add more monomorphic stuff Thanks Ian
+1 generalize prelude -1 the other proposals On May 22, 2013 7:57 PM, "Ian Lynagh" <ian@well-typed.com> wrote:
FWIW, my opinion would be
+1 Remove from Prelude 0 Generalize Prelude 0 Do nothing -1 Add more monomorphic stuff
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals... But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals... We have plenty of students who have trouble understanding existing functions and types themselves; if we were to suddenly find map, filter, etc. with generalised type signatures then it would confuse the matter even further (especially as they've only "seen" the standard Eq, Ord and Show classes, and even then only in deriving statements and type signatures to be able to use ==, /=, etc. rather than knowing how to write an instance of them themselves). (Admittedly, they only see these list functions in roughly the last third of the course; even so, despite having just written their own map, filter, etc. functions first for Strings and then generalising them to work on any list in a tutorial a few weeks back, when it came time to work on their assignment when map and filter would come in handy some still kept writing the list traversals by hand due to unfamiliarity of these functions when compared to all the manual list traversal they'd already done.) If the types in the Prelude were generalised, it might be possible to have a custom Prelude used for the course; however, for this to be used we'd either have to: a) get them to use rote boilerplate of {-# LANGUAGE NoImplicitPrelude #-} (or `import Prelude()') and importing the custom one; this would still require ensuring that students had the custom prelude installed on their own laptops, etc. b) write wrappers around ghc and ghci to load up the custom prelude instead, though even if we managed to get this to work we'd still need to somehow make sure all students would install equivalent wrappers on their own machine... and considering how much luck we've had with making sure they configured their editors to have the tab key insert four spaces instead of a tab character, I can see that being painful. Either way, we'd then find ourselves teaching a "custom" version of Haskell, and I don't exactly have fond memories of when I was taught Java in my first year of uni using a custom wrapper/library (and since my only programming experience to date was Pascal/Delphi, I can't really blame Java :p) I do, however, think that the Prelude is over-crowded and that Data.List should contain most of the list-specific functions (and it is weird when there is so much overlap between the two). So my actual votes for the current status of this proposal are: -1 for generalising the Prelude +1 for removing stuff from the Prelude (then people can import Data.List, Data.Traversable, Data.Foldable, etc. as they see fit without clashes) -1 for adding monomorphic stuff -0.5 for doing nothing
Regards, Malcolm.
On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ 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 Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous. - C.
El May 22, 2013, a las 9:06 PM, Casey McCann <cam@uptoisomorphism.net> escribió:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
- C.
I'd phrase it more nicely than that, but I agree with the point that you could still teach the course with haskell. Specifically, it seems like not much of a jump in abstraction to go from [Int] to [a] to List a to (Traversable f) => f a to (Functor f) => f a Tom
On 23 May 2013 11:24, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 9:06 PM, Casey McCann <cam@uptoisomorphism.net> escribió:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
- C.
I'd phrase it more nicely than that, but I agree with the point that you could still teach the course with haskell.
Specifically, it seems like not much of a jump in abstraction to go from
[Int] to [a] to List a to (Traversable f) => f a to (Functor f) => f a
I think it _is_ more of a jump... at least if we want them to eventually consider Traversable, Functor, etc. in the abstract sense and avoiding a "Traversable is like a <something>" tutorials; whilst it might be possible to give people learning Haskell to give them the intuition that a Functor is a container, how then do you make the jump to ((->) a) ? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
El May 22, 2013, a las 9:31 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> escribió:
On 23 May 2013 11:24, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 9:06 PM, Casey McCann <cam@uptoisomorphism.net> escribió:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
- C.
I'd phrase it more nicely than that, but I agree with the point that you could still teach the course with haskell.
Specifically, it seems like not much of a jump in abstraction to go from
[Int] to [a] to List a to (Traversable f) => f a to (Functor f) => f a
I think it _is_ more of a jump... at least if we want them to eventually consider Traversable, Functor, etc. in the abstract sense and avoiding a "Traversable is like a <something>" tutorials; whilst it might be possible to give people learning Haskell to give them the intuition that a Functor is a container, how then do you make the jump to ((->) a) ?
I really can't speak from experience as a professor, but it seems "Foldables are things that you can apply 'fold' to; Traversables are things you can traverse" would be much less scary than "monad" and "instance Functor ((->) e)" This could actually be a less rocky transition into typeclasses than Functor and friends... Tom
On 23 May 2013 11:06, Casey McCann <cam@uptoisomorphism.net> wrote:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
I think you missed my point... I'm not saying it's just because of the course I'm tutoring, but that I disagree with the contention of "people learning Haskell will pick this up relatively easier so we should just dismiss anything about not generalising because it will make it easier for new people". Also, not all people that learn Haskell are self-motivated in doing so, and thus won't take in the extra mental effort to understand how type-classes work right from the beginning. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
El May 22, 2013, a las 9:25 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> escribió:
On 23 May 2013 11:06, Casey McCann <cam@uptoisomorphism.net> wrote:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
I think you missed my point... I'm not saying it's just because of the course I'm tutoring, but that I disagree with the contention of "people learning Haskell will pick this up relatively easier so we should just dismiss anything about not generalising because it will make it easier for new people".
Also, not all people that learn Haskell are self-motivated in doing so, and thus won't take in the extra mental effort to understand how type-classes work right from the beginning.
If you want to avoid throwing people right into typeclasses, I could imagine teaching them: - To write map/fold/filter themselves, with simple [a] types - By giving them a small "module CS101 where" file, with monomorphic types of all our familiar friends, and then have them import with "import qualified CS101" and call "CS101.map" etc Tom
On 23 May 2013 11:35, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 9:25 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> escribió:
On 23 May 2013 11:06, Casey McCann <cam@uptoisomorphism.net> wrote:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
I think you missed my point... I'm not saying it's just because of the course I'm tutoring, but that I disagree with the contention of "people learning Haskell will pick this up relatively easier so we should just dismiss anything about not generalising because it will make it easier for new people".
Also, not all people that learn Haskell are self-motivated in doing so, and thus won't take in the extra mental effort to understand how type-classes work right from the beginning.
If you want to avoid throwing people right into typeclasses, I could imagine teaching them: - To write map/fold/filter themselves, with simple [a] types
Well, we have, and then tell them that they're so handy that they're predefined in the Prelude, Data.List, etc.
- By giving them a small "module CS101 where" file, with monomorphic types of all our familiar friends, and then have them import with "import qualified CS101" and call "CS101.map" etc
Sure. Irrespective of this and my previous points: if the generalisation proposal is successful, what happens to Data.List? * Will it still export specialised versions of functions? If so, then we have the current problem with Foldable/Traversable but reversed if you want to use any of the Data.List functions. * Not re-export functions available from the Prelude (in that case would `map' still exist or would we silently drop it in favour of fmap?) * Re-export the generalised functions with the generalised type signatures, which would look a little weird in a List-specific module. (And how would this all tie together with the current build/foldr fusion for lists?) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
On Wed, May 22, 2013 at 9:25 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
I think you missed my point... I'm not saying it's just because of the course I'm tutoring, but that I disagree with the contention of "people learning Haskell will pick this up relatively easier so we should just dismiss anything about not generalising because it will make it easier for new people".
There are arguable benefits to avoiding ad-hoc polymorphism at the very beginning when teaching programming, yes. I actually agree there. The Prelude is already hopeless on that front because of Num (and possibly Monad). It is very, very easy to get many of GHC's least helpful error messages as a beginner making minor mistakes with numeric literals. If the monomorphic approach is what you want, then do it properly and use a monomorphic alternate Prelude or a Haskell environment other than GHC, either of which the students ought to be more than capable of installing and using. Students averse to mental effort and following simple directions are why God invented "failing the course". - C.
This usecase is addressed by the fact that the haskell2010 and haskel98 packages would not be affected by this. If you need a largely static subset of Haskell there it is. -Edward On Wed, May 22, 2013 at 9:25 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 11:06, Casey McCann <cam@uptoisomorphism.net> wrote:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
So in other words, your contention is that the design of the core library of Haskell should be driven by the needs of an introductory programming course, which is not even attempting to teach Haskell specifically, aimed at students who can't even figure out how tab characters work? That's marvelous.
I think you missed my point... I'm not saying it's just because of the course I'm tutoring, but that I disagree with the contention of "people learning Haskell will pick this up relatively easier so we should just dismiss anything about not generalising because it will make it easier for new people".
Also, not all people that learn Haskell are self-motivated in doing so, and thus won't take in the extra mental effort to understand how type-classes work right from the beginning.
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I don't think so. You could just tell GHC / ghci to do Haskell 2010/98 and have the old base. This change does not constitute retconning prior base/preludes, but rather a new base / prelude that the community wishes to use going forward. (If I'm wrong, someone please correct me) Point being, old standards for base / prelude will still exist. Use those if you can't adjust your teaching materials. Granted the students won't be able to use as many libraries immediately in such a course, but that's your choice to make. On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals... But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals... We have plenty of students who have trouble understanding existing functions and types themselves; if we were to suddenly find map, filter, etc. with generalised type signatures then it would confuse the matter even further (especially as they've only "seen" the standard Eq, Ord and Show classes, and even then only in deriving statements and type signatures to be able to use ==, /=, etc. rather than knowing how to write an instance of them themselves). (Admittedly, they only see these list functions in roughly the last third of the course; even so, despite having just written their own map, filter, etc. functions first for Strings and then generalising them to work on any list in a tutorial a few weeks back, when it came time to work on their assignment when map and filter would come in handy some still kept writing the list traversals by hand due to unfamiliarity of these functions when compared to all the manual list traversal they'd already done.) If the types in the Prelude were generalised, it might be possible to have a custom Prelude used for the course; however, for this to be used we'd either have to: a) get them to use rote boilerplate of {-# LANGUAGE NoImplicitPrelude #-} (or `import Prelude()') and importing the custom one; this would still require ensuring that students had the custom prelude installed on their own laptops, etc. b) write wrappers around ghc and ghci to load up the custom prelude instead, though even if we managed to get this to work we'd still need to somehow make sure all students would install equivalent wrappers on their own machine... and considering how much luck we've had with making sure they configured their editors to have the tab key insert four spaces instead of a tab character, I can see that being painful. Either way, we'd then find ourselves teaching a "custom" version of Haskell, and I don't exactly have fond memories of when I was taught Java in my first year of uni using a custom wrapper/library (and since my only programming experience to date was Pascal/Delphi, I can't really blame Java :p) I do, however, think that the Prelude is over-crowded and that Data.List should contain most of the list-specific functions (and it is weird when there is so much overlap between the two). So my actual votes for the current status of this proposal are: -1 for generalising the Prelude +1 for removing stuff from the Prelude (then people can import Data.List, Data.Traversable, Data.Foldable, etc. as they see fit without clashes) -1 for adding monomorphic stuff -0.5 for doing nothing
Regards, Malcolm.
On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Good point - some courses still even use Hugs... Tom El May 22, 2013, a las 9:15 PM, Carter Schonwald <carter.schonwald@gmail.com> escribió:
I don't think so. You could just tell GHC / ghci to do Haskell 2010/98 and have the old base.
This change does not constitute retconning prior base/preludes, but rather a new base / prelude that the community wishes to use going forward. (If I'm wrong, someone please correct me)
Point being, old standards for base / prelude will still exist. Use those if you can't adjust your teaching materials. Granted the students won't be able to use as many libraries immediately in such a course, but that's your choice to make. On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
We have plenty of students who have trouble understanding existing functions and types themselves; if we were to suddenly find map, filter, etc. with generalised type signatures then it would confuse the matter even further (especially as they've only "seen" the standard Eq, Ord and Show classes, and even then only in deriving statements and type signatures to be able to use ==, /=, etc. rather than knowing how to write an instance of them themselves).
(Admittedly, they only see these list functions in roughly the last third of the course; even so, despite having just written their own map, filter, etc. functions first for Strings and then generalising them to work on any list in a tutorial a few weeks back, when it came time to work on their assignment when map and filter would come in handy some still kept writing the list traversals by hand due to unfamiliarity of these functions when compared to all the manual list traversal they'd already done.)
If the types in the Prelude were generalised, it might be possible to have a custom Prelude used for the course; however, for this to be used we'd either have to:
a) get them to use rote boilerplate of {-# LANGUAGE NoImplicitPrelude #-} (or `import Prelude()') and importing the custom one; this would still require ensuring that students had the custom prelude installed on their own laptops, etc.
b) write wrappers around ghc and ghci to load up the custom prelude instead, though even if we managed to get this to work we'd still need to somehow make sure all students would install equivalent wrappers on their own machine... and considering how much luck we've had with making sure they configured their editors to have the tab key insert four spaces instead of a tab character, I can see that being painful.
Either way, we'd then find ourselves teaching a "custom" version of Haskell, and I don't exactly have fond memories of when I was taught Java in my first year of uni using a custom wrapper/library (and since my only programming experience to date was Pascal/Delphi, I can't really blame Java :p)
I do, however, think that the Prelude is over-crowded and that Data.List should contain most of the list-specific functions (and it is weird when there is so much overlap between the two).
So my actual votes for the current status of this proposal are:
-1 for generalising the Prelude +1 for removing stuff from the Prelude (then people can import Data.List, Data.Traversable, Data.Foldable, etc. as they see fit without clashes) -1 for adding monomorphic stuff -0.5 for doing nothing
Regards, Malcolm.
On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 23 May 2013 09:15, Carter Schonwald <carter.schonwald@gmail.com> wrote:
I don't think so. You could just tell GHC / ghci to do Haskell 2010/98 and have the old base.
This change does not constitute retconning prior base/preludes, but rather a new base / prelude that the community wishes to use going forward. (If I'm wrong, someone please correct me)
Point being, old standards for base / prelude will still exist. Use those if you can't adjust your teaching materials. Granted the students won't be able to use as many libraries immediately in such a course, but that's your choice to make.
Indeed. If you want to teach Haskell like it's 1998, use -package haskell98. But seriously, if you want to teach Haskell without typeclasses, use Helium. If you don't really care about Haskell (and Ivan's case doesn't) then use Elm: it has no typeclasses, runs in-browser (no installation requirements! cross-platform!) and has cool graphics libraries. Conrad.
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
We have plenty of students who have trouble understanding existing functions and types themselves; if we were to suddenly find map, filter, etc. with generalised type signatures then it would confuse the matter even further (especially as they've only "seen" the standard Eq, Ord and Show classes, and even then only in deriving statements and type signatures to be able to use ==, /=, etc. rather than knowing how to write an instance of them themselves).
(Admittedly, they only see these list functions in roughly the last third of the course; even so, despite having just written their own map, filter, etc. functions first for Strings and then generalising them to work on any list in a tutorial a few weeks back, when it came time to work on their assignment when map and filter would come in handy some still kept writing the list traversals by hand due to unfamiliarity of these functions when compared to all the manual list traversal they'd already done.)
If the types in the Prelude were generalised, it might be possible to have a custom Prelude used for the course; however, for this to be used we'd either have to:
a) get them to use rote boilerplate of {-# LANGUAGE NoImplicitPrelude #-} (or `import Prelude()') and importing the custom one; this would still require ensuring that students had the custom prelude installed on their own laptops, etc.
b) write wrappers around ghc and ghci to load up the custom prelude instead, though even if we managed to get this to work we'd still need to somehow make sure all students would install equivalent wrappers on their own machine... and considering how much luck we've had with making sure they configured their editors to have the tab key insert four spaces instead of a tab character, I can see that being painful.
Either way, we'd then find ourselves teaching a "custom" version of Haskell, and I don't exactly have fond memories of when I was taught Java in my first year of uni using a custom wrapper/library (and since my only programming experience to date was Pascal/Delphi, I can't really blame Java :p)
I do, however, think that the Prelude is over-crowded and that Data.List should contain most of the list-specific functions (and it is weird when there is so much overlap between the two).
So my actual votes for the current status of this proposal are:
-1 for generalising the Prelude +1 for removing stuff from the Prelude (then people can import Data.List, Data.Traversable, Data.Foldable, etc. as they see fit without clashes) -1 for adding monomorphic stuff -0.5 for doing nothing
Regards, Malcolm.
On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr@gnu.org> wrote:
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing +1 More fun polls like this
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
If the Prelude is mandated as training wheels then I am +1 for jettisoning the Prelude for real Haskell programs; let it be training wheels, so labeled, and real programs should use something sensible. And the Prelude should not be imported at all by default if it's only there for teaching. +1 for generalization, -1 for the others, -10000000 for making the default suitable solely for tutelary purposes. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On 05/23/2013 03:22 AM, Brandon Allbery wrote:
On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
I don't know if I'd go quite _that_ for as Malcolm for the weightings for the different proposals...
But I was speaking with a few other tutors of an introductory CS/programming course that uses Haskell (note: it's teaching programming with Haskell, not teaching Haskell per se: for example, all pattern matchings must be done with case statements as the lecturer considers top-level pattern matching a Haskell-specific quirk) about these proposals...
If the Prelude is mandated as training wheels then I am +1 for jettisoning the Prelude for real Haskell programs; let it be training wheels, so labeled, and real programs should use something sensible. And the Prelude should not be imported at all by default if it's only there for teaching.
import TrainingWheels
has a nice ring to it... :)
On 23 May 2013 05:32, Malcolm Wallace <malcolm.wallace@me.com> wrote:
-20 for generalising the Prelude +1 for removals from the Prelude -1 for adding monomorphic stuff +1000 for doing nothing
You are all nuts. :-)
That is possibly true; at the very least we are all iconoclasts for caring about Haskell in the first place. I'm curious why you feel so strongly about doing nothing? Is there some personal cost, or do you imagine some kind of negative reaction from other people -- and if so what, and from who? Conrad.
+1 Generalise Prelude.mapM etc +1 Remove Prelude.mapM etc let vote3 = if Foldable is imported into the Prelude then subtract 1 else +1 vote3 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing On Wed, May 22, 2013 at 10:23 PM, Edward Kmett <ekmett@gmail.com> wrote:
+1 Generalise Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
On Wed, May 22, 2013 at 9:24 AM, <amindfv@gmail.com> wrote:
El May 22, 2013, a las 8:12 AM, Ian Lynagh <ian@well-typed.com> escribió:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
+1
* Remove Prelude.mapM etc
-1
* Add more monomorphic variants to Prelude (e.g. whenJust)
0
* Nothing
-1
Tom
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I'm another from the crowd of silence observers. It seems to me that we still don't have a fully specified proposal. In particular which functions are we discussing? Only those from Traversable and Foldable? map? It would be nice to make this clear with a concrete proposal. Despite this, here's my 2-pence, +1 Generalise Prelude.mapM etc 0 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing The monomorphic elements of the Prelude are an aesthetic wart and a significant inconvenience. Being a beginner in the not so distant past, I am also skeptical that these functions are significantly easier for beginners to grasp and use. Concerning removing mapM without replacement: I'd be concerned that moving such a frequently used function out of the Prelude might be a bit confusing for beginners. Given the prominence of Monads in Haskell, it might be perplexing to find (f)map exported by the Prelude yet not mapM. On the note of the mtl's exports, Wren suggests that removing this has been discussed previously to no avail. My Google-fu might be failing me but all I've been able to find is this[1] lone message. At the risk of introducing yet another code-breaking change, is there a reason removing these re-exports hasn't been discussed further? Cheers, - Ben [1] http://www.haskell.org/pipermail/libraries/2005-December/004666.html
This discussion currently is limited in scope to the types and combinators from Foldable and Traversable. As a concrete proposal, I proposed replacing the combinators in the Prelude that are duplicated from Foldable and Traversable, with the possible exception of 'concat' and 'concatMap'. Any further generalization would be a separate proposal. -Edward On Wed, May 22, 2013 at 11:16 AM, Ben Gamari <bgamari.foss@gmail.com> wrote:
I'm another from the crowd of silence observers. It seems to me that we still don't have a fully specified proposal. In particular which functions are we discussing? Only those from Traversable and Foldable? map? It would be nice to make this clear with a concrete proposal.
Despite this, here's my 2-pence,
+1 Generalise Prelude.mapM etc 0 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing
The monomorphic elements of the Prelude are an aesthetic wart and a significant inconvenience. Being a beginner in the not so distant past, I am also skeptical that these functions are significantly easier for beginners to grasp and use.
Concerning removing mapM without replacement: I'd be concerned that moving such a frequently used function out of the Prelude might be a bit confusing for beginners. Given the prominence of Monads in Haskell, it might be perplexing to find (f)map exported by the Prelude yet not mapM.
On the note of the mtl's exports, Wren suggests that removing this has been discussed previously to no avail. My Google-fu might be failing me but all I've been able to find is this[1] lone message. At the risk of introducing yet another code-breaking change, is there a reason removing these re-exports hasn't been discussed further?
Cheers,
- Ben
[1] http://www.haskell.org/pipermail/libraries/2005-December/004666.html
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Wed, May 22, 2013 at 11:16:04AM -0400, Ben Gamari wrote:
I'm another from the crowd of silence observers. It seems to me that we still don't have a fully specified proposal. In particular which functions are we discussing? Only those from Traversable and Foldable? map? It would be nice to make this clear with a concrete proposal.
Yes, my intention was to describe what I think a proposal should look like, not to make one. I think a proposal ought not be under a subject of "Burning bridges" too :-)
Concerning removing mapM without replacement: I'd be concerned that moving such a frequently used function out of the Prelude might be a bit confusing for beginners.
The Prelude is a bizarre snapshot of what was common (or perhaps even what existed?) more than a decade ago. For example, it includes 'mapM' and 'sequence', but not 'when'. Here are the usage counts for the ghc package: mapM 562 mapM_ 175 sequence 41 sequence_ 8 when 205 unless 84 and while this is only one package, I would be surprised if 'sequence' isn't generally less used than 'when'. I would also expect that most mapM users would also use when, so would need to import Control.Monad anyway, at which point there's no point having mapM in Prelude (although that argument is diminished if the generalised mapM is exported instead). The Prelude is also bizarre due to being very broad, which also causes headaches with where to put it when splitting base up (the IO functions in particular are problematic).
Given the prominence of Monads in Haskell, it might be perplexing to find (f)map exported by the Prelude yet not mapM.
Well, why should map be exported by Prelude? If you want to do other things with lists, like 'sort' them, then you need to import Data.List, which makes a lot of sense. But if you want to 'scanl1' a list (when's the last time you did that?), then for historical reasons the function is magically imported through the Prelude. So why shouldn't you need to tell the compiler (i.e. "import Data.List") if you want to do /anything/ with a list, including 'scanl1' or 'map'? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
Ian Lynagh <ian@well-typed.com> writes:
On Wed, May 22, 2013 at 11:16:04AM -0400, Ben Gamari wrote:
I'm another from the crowd of silence observers. It seems to me that we still don't have a fully specified proposal. In particular which functions are we discussing? Only those from Traversable and Foldable? map? It would be nice to make this clear with a concrete proposal.
Yes, my intention was to describe what I think a proposal should look like, not to make one. I think a proposal ought not be under a subject of "Burning bridges" too :-)
A fair point :)
Concerning removing mapM without replacement: I'd be concerned that moving such a frequently used function out of the Prelude might be a bit confusing for beginners.
The Prelude is a bizarre snapshot of what was common (or perhaps even what existed?) more than a decade ago. For example, it includes 'mapM' and 'sequence', but not 'when'. Here are the usage counts for the ghc package:
mapM 562 mapM_ 175 sequence 41 sequence_ 8 when 205 unless 84
and while this is only one package, I would be surprised if 'sequence' isn't generally less used than 'when'. I would also expect that most mapM users would also use when, so would need to import Control.Monad anyway, at which point there's no point having mapM in Prelude (although that argument is diminished if the generalised mapM is exported instead).
I agree that the subset of functions exposed by the Prelude is a bit strange. Perhaps when should be added; perhaps sequence should be dropped. Either way, both of these discussions are I think mostly orthogonal to the decision of making what is currently in the Prelude polymorphic.
The Prelude is also bizarre due to being very broad, which also causes headaches with where to put it when splitting base up (the IO functions in particular are problematic).
Given the prominence of Monads in Haskell, it might be perplexing to find (f)map exported by the Prelude yet not mapM.
Well, why should map be exported by Prelude?
If you want to do other things with lists, like 'sort' them, then you need to import Data.List, which makes a lot of sense. But if you want to 'scanl1' a list (when's the last time you did that?), then for historical reasons the function is magically imported through the Prelude.
So why shouldn't you need to tell the compiler (i.e. "import Data.List") if you want to do /anything/ with a list, including 'scanl1' or 'map'?
In the case of these monomorphic functions on lists you may have a point. That being said, I believe that fmap has a place in the Prelude and my original point holds in this case as well. I would argue that mapping over functors with pure functions and monadic actions are both needed often enough that requiring an import for either would be unduly onerous. I would be interested to hear if others disagree with this premise. Cheers, - Ben
On 22.05.2013 18:41, Ben Gamari wrote:
Ian Lynagh <ian@well-typed.com> writes:
The Prelude is a bizarre snapshot of what was common (or perhaps even what existed?) more than a decade ago. For example, it includes 'mapM' and 'sequence', but not 'when'. Here are the usage counts for the ghc package:
mapM 562 mapM_ 175 sequence 41 sequence_ 8 when 205 unless 84
and while this is only one package, I would be surprised if 'sequence' isn't generally less used than 'when'. I would also expect that most mapM users would also use when, so would need to import Control.Monad anyway, at which point there's no point having mapM in Prelude (although that argument is diminished if the generalised mapM is exported instead).
I agree that the subset of functions exposed by the Prelude is a bit strange. Perhaps when should be added; perhaps sequence should be dropped. Either way, both of these discussions are I think mostly orthogonal to the decision of making what is currently in the Prelude polymorphic.
The Prelude is also bizarre due to being very broad, which also causes headaches with where to put it when splitting base up (the IO functions in particular are problematic).
Given the prominence of Monads in Haskell, it might be perplexing to find (f)map exported by the Prelude yet not mapM.
Well, why should map be exported by Prelude?
If you want to do other things with lists, like 'sort' them, then you need to import Data.List, which makes a lot of sense. But if you want to 'scanl1' a list (when's the last time you did that?), then for historical reasons the function is magically imported through the Prelude.
So why shouldn't you need to tell the compiler (i.e. "import Data.List") if you want to do /anything/ with a list, including 'scanl1' or 'map'?
In the case of these monomorphic functions on lists you may have a point. That being said, I believe that fmap has a place in the Prelude and my original point holds in this case as well.
I would argue that mapping over functors with pure functions and monadic actions are both needed often enough that requiring an import for either would be unduly onerous. I would be interested to hear if others disagree with this premise.
When I use ghci as a calculator, I need the Prelude, including map. When I do serious programming, then it is mostly monadic, then I am fine with importing stuff. I do not need mapM in the Prelude. [But since it is there, and used in existing code, it should probably stay (in a generalized form).] -- 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 05/22/2013 01:12 PM, Ian Lynagh wrote:
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc +1 * Remove Prelude.mapM etc +1 * Add more monomorphic variants to Prelude (e.g. whenJust) -1 * Nothing -1
- ocharles
+1 Generalize Prelude -1 Remove from Prelude -1 Add more monomorphic stuff -1 Do nothing -- Vincent
On Wed, May 22, 2013 at 01:12:11PM +0100, Ian Lynagh wrote:
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc * Remove Prelude.mapM etc * Add more monomorphic variants to Prelude (e.g. whenJust) * Nothing
Wasn't there also mention of making Applicative a superclass of Monad? That might actually have less impact on beginners than generalizing the types of foldr and sum, and doing it first might allow us to rationalize the situation with some of the monad combinators that are clashing.
There is a painfully long chain of discussions on fixing the instance Applicative m => Monad m situation. I'd love to see that resolved as well! But I'd rather not tie all good things in the Haskell ecosystem to the one thing we've repeatedly demonstrated our lack of ability to accomplish. =( -Edward On Wed, May 22, 2013 at 6:22 PM, Ross Paterson <R.Paterson@city.ac.uk>wrote:
On Wed, May 22, 2013 at 01:12:11PM +0100, Ian Lynagh wrote:
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc * Remove Prelude.mapM etc * Add more monomorphic variants to Prelude (e.g. whenJust) * Nothing
Wasn't there also mention of making Applicative a superclass of Monad?
That might actually have less impact on beginners than generalizing the types of foldr and sum, and doing it first might allow us to rationalize the situation with some of the monad combinators that are clashing.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Wed, May 22, 2013 at 6:22 PM, Ross Paterson <R.Paterson@city.ac.uk> wrote:
Wasn't there also mention of making Applicative a superclass of Monad?
That might actually have less impact on beginners than generalizing the types of foldr and sum, and doing it first might allow us to rationalize the situation with some of the monad combinators that are clashing.
That would create rather more significant breakage though, would it not? The change discussed here should be relatively painless in comparison. Even if it's a good idea, which it is, and even if we want to do it, which we should, it warrants a separate proposal. As demonstrated here, the community is overwhelmingly in favor of generalizing mapM &c. anyway, so there's no need to make it dependent on another improvement. - C.
On 2013-05-23 00:33, Casey McCann wrote:
On Wed, May 22, 2013 at 6:22 PM, Ross Paterson <R.Paterson@city.ac.uk> wrote:
Wasn't there also mention of making Applicative a superclass of Monad?
Even if it's a good idea, which it is, and even if we want to do it, which we should, it warrants a separate proposal.
Before this thread derails more in the Applicative-Monad direction: I've been preparing a proposal, and the link to the current state can be found at the bottom. If you want to comment on its contents write me a private email or contact me on IRC (quchen). I'm planning to submit it here when I'm sure it makes good enough arguments and all the rough edges are gone. That said, let's get back to (exactly) the Foldable/Traversable issue. Greetings, David https://github.com/quchen/articles/blob/master/applicative_monad.md
+1 Generalize Prelude.mapM etc -1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Do nothing I do not know how the 3rd proposal came about. The discussion, that started with added whenJust, did not talk about adding it to the *Prelude*. We do not need more stuff in the Prelude. We do not want Prelude to generate import conflicts. At the same time, I think backward compatibility is important. (Cf. the 'catch' disaster.) Generalization is backward-compatible (for type-correct programs that do not exploit type inference to the maximum). +1 for adding whenJust to Control.Monad or Data.Maybe or so. Cheers, Andreas On 22.05.2013 14:12, Ian Lynagh wrote:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc * Remove Prelude.mapM etc * Add more monomorphic variants to Prelude (e.g. whenJust) * Nothing
If we're going to have a poll, then I think it should allow people to rank all the options. +1/-1 ona single option would only give a sense of whether an option is prefered to doing nothing, not whether it is the best option.
Thanks Ian
-- 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 22/05/13 08:12 AM, Ian Lynagh wrote:
> On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
>> I suggest that we start a poll for a single, concrete proposal. If the
>> poll forum is by email or similar, I further suggest that replies be
>> limited strictly to +1/-1.
> I think there are 4 things it has been suiggested that we might do:
> * Generalise Prelude.mapM etc
I've already given my +1 to this proposal, and I'm not likely to
change my opinion. I have to say, though, that the "etc" above is a
little sneaky. Now that the proposal has been overwhelmingly accepted,
can we narrow it down? I can see four different interpretations of the
"etc":
0. empty string;
1. "mapM_, sequence, and sequence_";
2. intersection of exports of Prelude, Foldable, and Traversable, which
would include the above and also foldl, foldr, any, all, and, or, sum,
product, maximum(By), minimum(By), concat(Map), elem, and notElem; and
3. every existing export of Prelude that can be generalized to Foldable
or Traversable, which would be all of the above and then some others
like map, filter, length, null, takeWhile, dropWhile, span, break, take,
drop, splitAt, and probably some more.
It's best if I clarify that I'd be happy with either of the last
two answers. I suspect the optimal solution lies somewhere between them.
In an earlier post in the thread I summarized a concrete list of what I thought might best be entailed, which is to take the generalized versions of the existing combinators from Data.Foldable and Data.Traversable, but not to go off and make up new things to generalize -- those I think rightfully belong in other proposals. So, the intent of me and many of the others I interacted with in putting forth the proposal was very much in the spirit of interpretation (2). The were however, two combinators in Data.Foldable that I wondered if we should include: Data.Foldable.concat and Data.Foldable.concatMap. I'm pretty much neutral on their inclusion or exclusion. Pros for including: Consistency. Leaving them behind in Data.Foldable means that you get back to importing with name collisions for just two combinators. Cons for including: concatMap is subsumed by foldMap concat is subsumed by both fold and by join for its role in (++) One can concoct a scenario where you use MonadPlus combinators to build up a list and tear it down with the existing concat. This is arguably "crossing the streams" as you are building up with one class and tearing down with another class constraint with no law relating the two, and so using the old Prelude 'concat' could help inference along -- otherwise why were you invoking it in the first place? Phrasing this as the intersection of the Foldable/Traversable API and the Prelude is interesting, because it would leave a few fold-like combinators in Data.Foldable alone. I'm somewhat neutral on whether we bring in the rest of the foldlM, etc. but if we're bringing in Foldable, I'd like to at least see foldMap, but that carries with it the caveat that foldMap references Monoid, which is not currently in the Prelude (and traverse references Applicative, also not currently in the Prelude). Assuming the Applicative m => Monad m proposal goes through at the same time (which seems exceedingly likely given the current polling, the Applicative class would wind up in the Prelude, resolving the tension for the latter, but exporting foldMap means we'd want at least the Monoid class as well. So to summarize the particular point in the design space that I've been advocating and spell out some of its consequences: The Prelude then exports Foldable(..), Traversable(..), Applicative(..), and Monoid(..). We upgrade the combinators in Prelude with the ones from Foldable and Traversable that collide with the existing names -- along with whatever resolution folks want on concat/concatMap. Data.Foldable continues to export the few folds that weren't in the Prelude or someone makes a case for bringing them in too, and it also re-exports Foldable(..) and the combinators we moved, to facilitate the non-breakage of existing code. Data.Traversable re-exports Traversable(..) and provides foldMapDefault, fmapDefault, mapAccumL and mapAccumR. Data.Monoid would still continue to hold the existing monoids, (<>), and re-exports Monoid(..). Control.Applicative would still continue to export the instances, Alternative(..), combinators, and re-exports Applicative(..). -Edward On Sun, May 26, 2013 at 12:38 AM, Mario Blažević <blamario@acanac.net>wrote:
On 22/05/13 08:12 AM, Ian Lynagh wrote:
On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
I suggest that we start a poll for a single, concrete proposal. If the poll forum is by email or similar, I further suggest that replies be limited strictly to +1/-1.
I think there are 4 things it has been suiggested that we might do: * Generalise Prelude.mapM etc
I've already given my +1 to this proposal, and I'm not likely to change my opinion. I have to say, though, that the "etc" above is a little sneaky. Now that the proposal has been overwhelmingly accepted, can we narrow it down? I can see four different interpretations of the "etc":
0. empty string; 1. "mapM_, sequence, and sequence_"; 2. intersection of exports of Prelude, Foldable, and Traversable, which would include the above and also foldl, foldr, any, all, and, or, sum, product, maximum(By), minimum(By), concat(Map), elem, and notElem; and 3. every existing export of Prelude that can be generalized to Foldable or Traversable, which would be all of the above and then some others like map, filter, length, null, takeWhile, dropWhile, span, break, take, drop, splitAt, and probably some more.
It's best if I clarify that I'd be happy with either of the last two answers. I suspect the optimal solution lies somewhere between them.
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
On Sun, May 26, 2013 at 04:46:51AM -0400, Edward Kmett wrote:
The Prelude then exports Foldable(..), Traversable(..), Applicative(..), and Monoid(..).
What happens to functions like Control.Monad.mapM and Data.List.foldr? Are they removed, re-exports of the generalised functions, or do they remain as the specialised variants? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
Control.Monad.mapM should be generalized. You *have* to import Control.Monad for many things. Having it randomly dump a worse version of a combinator on you seems to be painfully arbitrary. Data.List.foldr, etc. is a tougher call. Similar to Control.Monad you have to import it for many combinators, on the other hand you seem to at least nominally be asking for combinators for working with lists by implementing it. As you mentioned, I see 3 ways to proceed for Data.List.foldr and their ilk. 1.) Given that Prelude is then exporting a type that subsumes it one option is to just remove them from Data.List. This would break some code that was explicitly referencing the qualified import from Data.List. 2.) Another option is to keep the more restricted type for Data.List.foldr. This breaks other code that relied on the fact that this was a re-export of the Prelude type to avoid needing qualification for those functions. If one of those proposals for re-exporting type restricted forms of things worked you might be able to get some traction here, but in their absence it strikes me as an awkward compromise. Lots of code imports Data.List unqualified. 3.) Data.List can just re-export the version from the Prelude. This means somewhat counter-intuitively that Data.List.foldr is generalized to Foldable, but it means that existing code that imported Data.List and just called foldr unqualified continues to work unmodified. I tend to favor option 3 because the most existing code works with it unmodified, despite the slightly counter-intuitive state it puts things in. If it was possible to deprecate a re-export of a function from a module, deprecating the re-export of the foldr-like functions from Data.List would provide a path towards a more sane final state. Mind you, I say this as 're-export the version from the Prelude' rather than have the Prelude re-export the version from Control.Monad not as a statement that we should flip any dependencies around in the implementation, but merely in a conversational sense based on how the modules are seen by the end user. Where the dependencies run the other way, obviously re-exports must flow the other way around. -Edward On Tue, May 28, 2013 at 12:44 PM, Ian Lynagh <ian@well-typed.com> wrote:
On Sun, May 26, 2013 at 04:46:51AM -0400, Edward Kmett wrote:
The Prelude then exports Foldable(..), Traversable(..), Applicative(..), and Monoid(..).
What happens to functions like Control.Monad.mapM and Data.List.foldr?
Are they removed, re-exports of the generalised functions, or do they remain as the specialised variants?
Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
On 28 May 2013 19:30, Edward Kmett <ekmett@gmail.com> wrote:
If it was possible to deprecate a re-export of a function from a module, deprecating the re-export of the foldr-like functions from Data.List would provide a path towards a more sane final state.
I added this use-case to the existing ticket on the deprecate exports feature request: http://hackage.haskell.org/trac/ghc/ticket/4879#comment:10
On Sun, 19 May 2013, Herbert Valerio Riedel wrote:
On 2013-05-18 16:08:33 +0200, Ian Lynagh wrote:
[...]
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1
I'd just leave Prelude as it is, in order to be able to introduce people to Haskell without doing any configuration. Experts can configure GHCi to import any default set of functions they like.
On 2013-05-19 10:38:28 +0200, Henning Thielemann wrote:
On Sun, 19 May 2013, Herbert Valerio Riedel wrote:
On 2013-05-18 16:08:33 +0200, Ian Lynagh wrote:
[...]
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
+1
I'd just leave Prelude as it is, in order to be able to introduce people to Haskell without doing any configuration. Experts can configure GHCi to import any default set of functions they like.
I'm not sure that beginners being introduced to Monad operations will start using the sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m () mapM :: Monad m => (a -> m b) -> [a] -> m [b] mapM_ :: Monad m => (a -> m b) -> [a] -> m () operations and not need an 'import Control.Monad' real soon afterwards anyway IMHO OTOH, having those four names above defined in the global Prelude namespace makes it more cumbersome to introduce beginners to Traversable/Foldable, as you'd have to explain them how to workaround the symbol clashes by using qualified imports or Prelude-hiding imports... cheers, hvr
On Sat, May 18, 2013 at 03:08:33PM +0100, Ian Lynagh wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
The issue here is that his would make it very hard to write backward compatible code. We already have seen this by removing Prelude.catch. GHC HQ mitigated this by making a "hidden import" a warning. But if you want -Wall-sane code you still need to always import Control.Exception qualified. Personally I'm strongly against removing the monomorphic versions without providing suitable alternatives. Cheers, Simon
On Mon, May 20, 2013 at 11:47:52AM +0200, Simon Hengel wrote:
On Sat, May 18, 2013 at 03:08:33PM +0100, Ian Lynagh wrote:
On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:
On 15 May 2013 18:14, Edward Kmett <ekmett@gmail.com> wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply.
I'd prefer to remove the monomorphic functions, but not to add anything to Prelude.
The issue here is that his would make it very hard to write backward compatible code. We already have seen this by removing Prelude.catch. GHC HQ mitigated this by making a "hidden import" a warning. But if you want -Wall-sane code you still need to always import Control.Exception qualified.
I think the conclusion of the base splitting discussion was that we should split base up, and make a new 'base' package that re-exports things from the split-up packages. Perhaps we should take this opportunity to slim down the Prelude, putting the slimmed-down version in one of the split packages, but leaving the current Prelude in the 'base' package. That way packages will continue to be able to depend on base, and get the existing Prelude, but when they switch to the split versions they will need to add imports and resolve ambiguities as necessary. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
+1 On 05/15/2013 06:14 PM, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-Edward
On Wed, 15 May 2013, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point. I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-1 1. Prelude should be backwards compatible and since it is implicitly imported everywhere, barriers for changing something should be especially high. 2. I see a shift away from Prelude functions to more generalized functions (Foldable.mapM_, Traversable.mapM, Category.(.), RMonad, alternative numeric classes etc.) This way people have to import identifiers explicitly, which is a good idea anyway.
+1. I think the Prelude should be a general module of the most commonly needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
On Wed, 15 May 2013, David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know how to import. Putting the most general functions into Prelude does not work because: 1. There are often multiple sensible generalizations of a Prelude function. 2. You have to add more type annotations since types cannot be infered from the functions. There is simply no need to change Prelude and all packages that rely on specific types. Just don't be lazy and import the stuff you need! I should change my vote to: -10
-1, for the reasons given by Henning. If we're going to be changing stuff in Prelude, why not start with Functor/Monad? On Thu, May 16, 2013 at 5:04 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Wed, 15 May 2013, David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly
needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know how to import. Putting the most general functions into Prelude does not work because:
1. There are often multiple sensible generalizations of a Prelude function.
2. You have to add more type annotations since types cannot be infered from the functions.
There is simply no need to change Prelude and all packages that rely on specific types. Just don't be lazy and import the stuff you need!
I should change my vote to:
-10
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
I'd be +1 for doing that, too. On Wed, May 15, 2013 at 8:16 PM, John Lato <jwlato@gmail.com> wrote:
-1, for the reasons given by Henning.
If we're going to be changing stuff in Prelude, why not start with Functor/Monad?
On Thu, May 16, 2013 at 5:04 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Wed, 15 May 2013, David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly
needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know how to import. Putting the most general functions into Prelude does not work because:
1. There are often multiple sensible generalizations of a Prelude function.
2. You have to add more type annotations since types cannot be infered from the functions.
There is simply no need to change Prelude and all packages that rely on specific types. Just don't be lazy and import the stuff you need!
I should change my vote to:
-10
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1 on that functor monad bit On Thursday, May 16, 2013, Edward Kmett wrote:
I'd be +1 for doing that, too.
On Wed, May 15, 2013 at 8:16 PM, John Lato <jwlato@gmail.com<javascript:_e({}, 'cvml', 'jwlato@gmail.com');>
wrote:
-1, for the reasons given by Henning.
If we're going to be changing stuff in Prelude, why not start with Functor/Monad?
On Thu, May 16, 2013 at 5:04 AM, Henning Thielemann < lemming@henning-thielemann.de <javascript:_e({}, 'cvml', 'lemming@henning-thielemann.de');>> wrote:
On Wed, 15 May 2013, David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly
needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know how to import. Putting the most general functions into Prelude does not work because:
1. There are often multiple sensible generalizations of a Prelude function.
2. You have to add more type annotations since types cannot be infered from the functions.
There is simply no need to change Prelude and all packages that rely on specific types. Just don't be lazy and import the stuff you need!
I should change my vote to:
-10
______________________________**_________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
_______________________________________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/mailman/listinfo/libraries
+1 for Functor/Monad On May 19, 2013, at 1:59 PM, Carter Schonwald wrote:
+1 on that functor monad bit
On Thursday, May 16, 2013, Edward Kmett wrote: I'd be +1 for doing that, too.
On Wed, May 15, 2013 at 8:16 PM, John Lato <jwlato@gmail.com> wrote: -1, for the reasons given by Henning.
If we're going to be changing stuff in Prelude, why not start with Functor/Monad?
On Thu, May 16, 2013 at 5:04 AM, Henning Thielemann <lemming@henning-thielemann.de> wrote:
On Wed, 15 May 2013, David Luposchainsky wrote:
+1. I think the Prelude should be a general module of the most commonly needed functions, which (generalized) folds and traversals are certainly part of; right now it feels more like a beginner module at times.
It is certainly a kind of beginner module, but that's good. Experts know how to import. Putting the most general functions into Prelude does not work because:
1. There are often multiple sensible generalizations of a Prelude function.
2. You have to add more type annotations since types cannot be infered from the functions.
There is simply no need to change Prelude and all packages that rely on specific types. Just don't be lazy and import the stuff you need!
I should change my vote to:
-10
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Sun, 19 May 2013, Carter Schonwald wrote:
+1 on that functor monad bit
Can you please change the subject when you start a new discussion? It will be really hard to follow later. The discussion started with whenJust and now we are at the third or fourth proposal, depending on whether you count Ian's comment as an individual proposal.
Edward Kmett <ekmett@gmail.com> writes:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
A hearty +1 for this. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net
-1 for the reasons given by Henning. Also more polymorphic types generally cause worse error messages. On 15/05/2013 17:14, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-Edward
On Wed, May 15, 2013 at 10:25 AM, Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> wrote:
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
_________________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://www.haskell.org/__mailman/listinfo/libraries <http://www.haskell.org/mailman/listinfo/libraries>
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
+1. Currently something is broken since in the presence of import Data.Traversable (mapM) the rest of the import list looks like this: import Prelude hiding (mapM) import Control.Monad.Identity hiding (mapM) import Control.Monad.State hiding (mapM) import Control.Monad.Error hiding (mapM) import Control.Monad.Reader hiding (mapM) I don't know why all these modules export a mapM that only works for lists, rather than the generic mapM from Traversable. --Andreas On 16.05.13 9:22 AM, Ganesh Sittampalam wrote:
-1 for the reasons given by Henning.
Also more polymorphic types generally cause worse error messages.
On 15/05/2013 17:14, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-Edward
On Wed, May 15, 2013 at 10:25 AM, Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> wrote:
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
-- 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 Thu, 16 May 2013, Andreas Abel wrote:
import Prelude hiding (mapM) import Control.Monad.Identity hiding (mapM) import Control.Monad.State hiding (mapM) import Control.Monad.Error hiding (mapM) import Control.Monad.Reader hiding (mapM)
I don't know why all these modules export a mapM that only works for lists, rather than the generic mapM from Traversable.
1. Import of Control.Monad.State et.al. without qualification requires very small version ranges for mtl according to the PVP, which you certainly do not want. 2. Import with hiding is a very bad idea, too, since if mtl will be cleaned up and 'mapM' is no longer re-exported, your imports will break. 3. I switched to 'transformers' completely long ago. It does not re-export any monad helper functions.
On Thu, May 16, 2013 at 1:51 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
3. I switched to 'transformers' completely long ago. It does not re-export any monad helper functions.
This! I know it's off-topic but: I did the same. MTL has some nice features... it wasn't worth the hell of it's re-exports. Re-exporting is the devil's work, I say! - Mark
I would be happy to see a libraries request that proposed removing all the re-exports from the next major release of mtl. I've never been a fan of the current approach. It makes is so if you need to hide something you need to hide it from up 10 sources some times. On Wed, May 22, 2013 at 12:38 AM, Mark Lentczner <mark.lentczner@gmail.com>wrote:
On Thu, May 16, 2013 at 1:51 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
3. I switched to 'transformers' completely long ago. It does not re-export any monad helper functions.
This! I know it's off-topic but: I did the same. MTL has some nice features... it wasn't worth the hell of it's re-exports. Re-exporting is the devil's work, I say!
- Mark
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
IMO this is 100% "Polymorphism: You're Doing It Wrong." I +1 edwardk's suggestion of updating the prelude, but couldn't "classy prelude"-style drop-ins allow the same? Tom El May 16, 2013, a las 3:44 AM, Andreas Abel <andreas.abel@ifi.lmu.de> escribió:
+1.
Currently something is broken since in the presence of
import Data.Traversable (mapM)
the rest of the import list looks like this:
import Prelude hiding (mapM) import Control.Monad.Identity hiding (mapM) import Control.Monad.State hiding (mapM) import Control.Monad.Error hiding (mapM) import Control.Monad.Reader hiding (mapM)
I don't know why all these modules export a mapM that only works for lists, rather than the generic mapM from Traversable.
--Andreas
On 16.05.13 9:22 AM, Ganesh Sittampalam wrote:
-1 for the reasons given by Henning.
Also more polymorphic types generally cause worse error messages.
On 15/05/2013 17:14, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-Edward
On Wed, May 15, 2013 at 10:25 AM, Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> wrote:
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk <mailto:haskell@benmachine.co.uk>> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
-- 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
+1 to this proposal. On Wednesday, May 15, 2013, Edward Kmett wrote:
Personally, I'd be all for just moving Foldable (and Traversable) into the Prelude and retiring the monomorphic versions of the functions they supply. Both abstractions have born the test of time, and its hard to even envision Haskell without them at this point.
I'm somewhat leery that we coud get this proposal past the "but it makes it harder to introduce people to Haskell" backlash, but I'd wholeheartedly support it.
-Edward
On Wed, May 15, 2013 at 10:25 AM, Ben Millwood <haskell@benmachine.co.uk<javascript:_e({}, 'cvml', 'haskell@benmachine.co.uk');>
wrote:
On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:
* Ben Millwood <haskell@benmachine.co.uk <javascript:_e({}, 'cvml', 'haskell@benmachine.co.uk');>> [2013-05-12 10:11:01+0100]
You can mostly minimise harm by only hiding specific things, but that's still more effort than I feel like I should have to go to. I think if we decide that the Foldable approach is useful enough to go in base, we should not make it a second-class citizen.
... except it is in base already :)
Roman
Yeah, sorry, to clarify: *since* we think it is important enough to go in base, we should make it easy to use as well.
______________________________**_________________ Libraries mailing list Libraries@haskell.org <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
On Fri, May 10, 2013 at 1:44 PM, Gabriel Gonzalez <gabriel439@gmail.com> wrote:
How about I just write a blog post teaching people how to use `for_` (and more generally, how to use `Maybe`'s `Foldable` instance)? I know Oliver Charles wrote a similar post in his 24 days of Hackage, and maybe I could build on that a bit more and perhaps make it as Google-able as possible so it comes up as the top result when people search for keywords like `whenJust` and other `Maybe` idioms.
Sounds like a good post -- but, only if people can find it at the right time. Is there some way we can add something to the haddock/hoogle docs so that people looking for `whenJust` can be told that they are looking for `for_`? I just wrote `whenJust` myself a few days ago -- not realizing that for_ is what I wanted. I don't really need a whole tutorial for that -- just a 'you mean for_' would be enough. But.. it would need to be in the Control.Monad and/or Data.Maybe haddocks for me to have seen it.. - jeremy
This is nothing but obfuscation, whenJust is clearly more readable than for_. whenJust is monomorphic too. On Fri, 10 May 2013 11:44:42 -0700 Gabriel Gonzalez <gabriel439@gmail.com> wrote:
How about I just write a blog post teaching people how to use `for_` (and more generally, how to use `Maybe`'s `Foldable` instance)? I know Oliver Charles wrote a similar post in his 24 days of Hackage, and maybe I could build on that a bit more and perhaps make it as Google-able as possible so it comes up as the top result when people search for keywords like `whenJust` and other `Maybe` idioms.
On Fri, May 10, 2013 at 11:25 AM, <libraries-request@haskell.org> wrote:
Send Libraries mailing list submissions to libraries@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to libraries-request@haskell.org
You can reach the person managing the list at libraries-owner@haskell.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."
Today's Topics:
1. Re: Control.Monad proposal: Add whenJust (Edward Kmett) 2. Re: Control.Monad proposal: Add whenJust (Evan Laforge) 3. Re: Control.Monad proposal: Add whenJust (Simon Hengel) 4. Re: Control.Monad proposal: Add whenJust (Andreas Abel) 5. Re: Control.Monad proposal: Add whenJust (Ivan Lazar Miljenovic) 6. Re: Control.Monad proposal: Add whenJust (Ganesh Sittampalam) 7. Re: Control.Monad proposal: Add whenJust (Petr Pudl?k)
----------------------------------------------------------------------
Message: 1 Date: Fri, 10 May 2013 07:16:53 -0400 From: Edward Kmett <ekmett@gmail.com> Subject: Re: Control.Monad proposal: Add whenJust To: Niklas Hamb?chen <mail@nh2.me> Cc: Haskell Libraries <libraries@haskell.org> Message-ID: < CAJumaK8XJrtdrXQfVb3pdi193ghz9ZEX8Q-MnVd435tDt5YFbg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
I'm -1 on this, due to it just further obfuscating the fact that Data.Foldable.for_ already exists.
On Fri, May 10, 2013 at 2:13 AM, Niklas Hamb?chen <mail@nh2.me> wrote:
I would like to propose the addition of
whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) f = f x whenJust _ _ = return ()
to Control.Monad, in the section
"Conditional execution of monadic expressions"
next to
guard :: MonadPlus m => Bool -> m () when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m ()
Why?
It would allow us to write more readable code and fit well into the group of similar functions of this style.
Compare
mUser <- lookupUser
whenJust mUser email
or
whenJust mUser $ \user -> do putStrLn "Mailing!" email user
with some currently available alternatives:
case mUser of Just user -> do putStrLn "Mailing!" email user Nothing -> return ()
(Default base case clutter.)
import Data.Foldable
forM_ mUser $ \user -> do putStrLn "Mailing!" email user
(Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.)
Some more dissatisfying alternatives:
maybe (return ()) (\user -> do putStrLn "Mailing!" email user ) mUser
flip (maybe (return ())) mUser $ \user -> do putStrLn "Mailing!" email user
import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift)
_ <- runMaybeT $ return mUser >>= \user -> lift $ do putStrLn "Mailing!" email user return ()
Alternative names:
- withJust, analog to withFile and withForeignPtr
Any comments?
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I for one do not view 'monomorphic too' as a feature. Sent from my iPad On May 10, 2013, at 4:36 PM, kudah <kudahkukarek@gmail.com> wrote:
This is nothing but obfuscation, whenJust is clearly more readable than for_. whenJust is monomorphic too.
On Fri, 10 May 2013 11:44:42 -0700 Gabriel Gonzalez <gabriel439@gmail.com> wrote:
How about I just write a blog post teaching people how to use `for_` (and more generally, how to use `Maybe`'s `Foldable` instance)? I know Oliver Charles wrote a similar post in his 24 days of Hackage, and maybe I could build on that a bit more and perhaps make it as Google-able as possible so it comes up as the top result when people search for keywords like `whenJust` and other `Maybe` idioms.
On Fri, May 10, 2013 at 11:25 AM, <libraries-request@haskell.org> wrote:
Send Libraries mailing list submissions to libraries@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to libraries-request@haskell.org
You can reach the person managing the list at libraries-owner@haskell.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."
Today's Topics:
1. Re: Control.Monad proposal: Add whenJust (Edward Kmett) 2. Re: Control.Monad proposal: Add whenJust (Evan Laforge) 3. Re: Control.Monad proposal: Add whenJust (Simon Hengel) 4. Re: Control.Monad proposal: Add whenJust (Andreas Abel) 5. Re: Control.Monad proposal: Add whenJust (Ivan Lazar Miljenovic) 6. Re: Control.Monad proposal: Add whenJust (Ganesh Sittampalam) 7. Re: Control.Monad proposal: Add whenJust (Petr Pudl?k)
----------------------------------------------------------------------
Message: 1 Date: Fri, 10 May 2013 07:16:53 -0400 From: Edward Kmett <ekmett@gmail.com> Subject: Re: Control.Monad proposal: Add whenJust To: Niklas Hamb?chen <mail@nh2.me> Cc: Haskell Libraries <libraries@haskell.org> Message-ID: < CAJumaK8XJrtdrXQfVb3pdi193ghz9ZEX8Q-MnVd435tDt5YFbg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
I'm -1 on this, due to it just further obfuscating the fact that Data.Foldable.for_ already exists.
On Fri, May 10, 2013 at 2:13 AM, Niklas Hamb?chen <mail@nh2.me> wrote:
I would like to propose the addition of
whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () whenJust (Just x) f = f x whenJust _ _ = return ()
to Control.Monad, in the section
"Conditional execution of monadic expressions"
next to
guard :: MonadPlus m => Bool -> m () when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m ()
Why?
It would allow us to write more readable code and fit well into the group of similar functions of this style.
Compare
mUser <- lookupUser
whenJust mUser email
or
whenJust mUser $ \user -> do putStrLn "Mailing!" email user
with some currently available alternatives:
case mUser of Just user -> do putStrLn "Mailing!" email user Nothing -> return ()
(Default base case clutter.)
import Data.Foldable
forM_ mUser $ \user -> do putStrLn "Mailing!" email user
(Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.)
Some more dissatisfying alternatives:
maybe (return ()) (\user -> do putStrLn "Mailing!" email user ) mUser
flip (maybe (return ())) mUser $ \user -> do putStrLn "Mailing!" email user
import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift)
_ <- runMaybeT $ return mUser >>= \user -> lift $ do putStrLn "Mailing!" email user return ()
Alternative names:
- withJust, analog to withFile and withForeignPtr
Any comments?
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (43)
-
amindfv＠gmail.com -
Andrea Vezzosi -
Andreas Abel -
Anthony Cowley -
Bardur Arantsson -
Bas van Dijk -
Ben -
Ben Gamari -
Ben Millwood -
Brandon Allbery -
Carter Schonwald -
Casey McCann -
Chris Seaton -
Conrad Parker -
Dan Doel -
David Luposchainsky -
David Virebayre -
Edward Kmett -
Felipe Almeida Lessa -
Gabriel Gonzalez -
Ganesh Sittampalam -
Gwern Branwen -
Henning Thielemann -
Henning Thielemann -
Herbert Valerio Riedel -
Ian Lynagh -
Ivan Lazar Miljenovic -
Jake McArthur -
Jeremy Shaw -
John Lato -
John Wiegley -
kudah -
Malcolm Wallace -
Mario Blažević -
Mark Lentczner -
Oliver Charles -
Petr Pudlák -
Roman Cheplyaka -
Ross Paterson -
Simon Hengel -
Simon Peyton-Jones -
Vincent Hanquez -
wren ng thornton