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 wrote:

On Fri, May 10, 2013 at 2:54 PM, Chris Seaton 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 Fri, May 10, 2013 at 5:04 PM, Andreas Abel 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.

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, 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 ...

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.

* Ben Millwood [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

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 wrote:

On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:

...

* Ben Millwood [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/librarieshttp://www.haskell.org/mailman/listinfo/libraries

On Wed, May 15, 2013 at 10:40:45PM +0200, Bas van Dijk wrote:

On 15 May 2013 18: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.

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

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 wrote:

On May 18, 2013 10:09 PM, "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 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

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 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 wrote:

...

On May 18, 2013 10:09 PM, "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 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

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 wrote:

...

On May 18, 2013 10:09 PM, "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 wrote:

...

Personally, I'd be all for just moving Foldable (and Traversable)

...

...

...

Prelude and retiring the monomorphic versions of the functions

into the 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

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 > 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

...

wrote:

...

On May 18, 2013 10:09 PM, "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 >

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

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 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

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

| 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

well said, On Tue, May 21, 2013 at 2:57 AM, Edward Kmett 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

...

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

On Tue, May 21, 2013 at 2:57 AM, Edward Kmett 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.

On Wed, May 22, 2013 at 8:18 AM, John Wiegley wrote:

...

...

...

...

...

Casey McCann 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 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

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 mailto:carter.schonwald@gmail.com> wrote:

+1

On Wed, May 22, 2013 at 3:40 AM, Herbert Valerio Riedel 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

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/

+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, wrote:

El May 22, 2013, a las 8:12 AM, Ian Lynagh 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 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 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, mailto:amindfv@gmail.com> wrote:

El May 22, 2013, a las 8:12 AM, Ian Lynagh 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 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 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, wrote:

...

El May 22, 2013, a las 8:12 AM, Ian Lynagh 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 May 22, 2013, at 11: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 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 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, wrote:

...

El May 22, 2013, a las 8:12 AM, Ian Lynagh 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 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

-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 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

FWIW, my opinion would be +1 Remove from Prelude 0 Generalize Prelude 0 Do nothing -1 Add more monomorphic stuff Thanks Ian

On 23 May 2013 07:32, Malcolm Wallace 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 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

El May 22, 2013, a las 9:06 PM, Casey McCann escribió:

On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic wrote:

...

On 23 May 2013 07:32, Malcolm Wallace 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

El May 22, 2013, a las 9:31 PM, Ivan Lazar Miljenovic escribió:

On 23 May 2013 11:24, wrote:

...

El May 22, 2013, a las 9:06 PM, Casey McCann escribió:

...

On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic wrote:

...

On 23 May 2013 07:32, Malcolm Wallace 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

El May 22, 2013, a las 9:25 PM, Ivan Lazar Miljenovic escribió:

On 23 May 2013 11:06, Casey McCann wrote:

...

On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic wrote:

...

On 23 May 2013 07:32, Malcolm Wallace 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 Wed, May 22, 2013 at 9:25 PM, Ivan Lazar Miljenovic 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.

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 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 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

On 23 May 2013 09:15, Carter Schonwald 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 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 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 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 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... :)

+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 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, wrote:

...

El May 22, 2013, a las 8:12 AM, Ian Lynagh 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

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 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

Ian Lynagh 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 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

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.

On Wed, May 22, 2013 at 6:22 PM, Ross Paterson 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.

+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/

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ć 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/librarieshttp://www.haskell.org/mailman/listinfo/libraries

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 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 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

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 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 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/

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.

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

I'd be +1 for doing that, too. On Wed, May 15, 2013 at 8:16 PM, John Lato 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/librarieshttp://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list 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 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 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

...

...

...

...

Edward Kmett 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. 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 mailto:haskell@benmachine.co.uk> wrote:

On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:

* Ben Millwood 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, 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

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 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 mailto:haskell@benmachine.co.uk> wrote:

On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:

* Ben Millwood 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

...

wrote:

...

On Wed, May 15, 2013 at 08:01:52AM +0300, Roman Cheplyaka wrote:

...

* Ben Millwood > [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/librarieshttp://www.haskell.org/mailman/listinfo/libraries