of course things will break. Things also break in easily fixable ways every major ghc version (and that doesn't stop each new GHC major version from being progressively more awesom). And thats ok. "all of hackage" isnt an informative test. Its ok, we have a type system, we'll know exactly what to change to make it all better again, thats kinda a big upside to having a type system after all. Mostly just adding some ":: [sometypehere]" constraints and then problems solved. thats a wonderfully easy breakage, an eminently patchable one even. There will no doubt be much patching of many actively maintained libs around ghc 7.8's release anyways, so why not amortize that effort to improve prelude while we're at it? Thats a great time to improve things. On Tue, May 21, 2013 at 1:18 AM, Krzysztof Skrzętnicki wrote:

I'm not convinced nothing will break. From my experience if you change anything in such high impact place as Prelude you are unlikely not to break anything. You are making some functions more generic and this can easily create ambiguity.

Just try compiling whole Hackage with modified Prelude and see what the results are.

Best regards, Krzysztof Skrzętnicki

On Tue, May 21, 2013 at 7:06 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

lets see what concerns there are

1) will any code break? Nope! In fact, it's trivial to provide a shim that only exposes the list monomorphic versions.

2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes. The various list specific versions of the foldable codes actually **confuses** smart software folks who are starting to learn haskell for fun.

I can't explain to a smart engineer *any* reason why minimum :: Ordhttp://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Or... a => [a] -> a exists in prelude. I *can* explain why something like minimum :: ( Foldablehttp://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.htm... t, Ordhttp://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t:O... a) => t a -> a would be useful and deserving of being in the standard prelue.

I've actually had to explain to a smart python engineering friend who's learning haskell this very problem. (that the list only versions are there for no deep reason aside from some pedagogical approach from over a decade ago that is no longer used)

tl;dr no code will break, there will be less inessential nonuniformity that doesn't aid in engineering or learning with haskell, so a win in every direction.

lets make things happen.

-Carter

On Mon, May 20, 2013 at 11:04 PM, wrote:

...

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 5/19/13 7:25 PM, Anthony Cowley wrote:

...

I think this issue may be too big to rely on mailing list +1s. Is

...

...

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,

On Mon, May 20, 2013 at 7:49 PM, wren ng thornton wrote: there 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

_______________________________________________ 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 12:26 PM, Henning Thielemann wrote:

On Tue, 21 May 2013, Carter Schonwald wrote:

...

thats a wonderfully easy breakage, an eminently patchable one even. There will no doubt be much patching of many actively maintained libs around ghc 7.8's release anyways, so why not amortize that effort to improve prelude while we're at it? Thats a great time to improve things.

I still don't see, why Data.Foldable is less standard than Prelude. Both are in 'base'. The difference is just, that you have to import the first one and not the other one. If this is too much effort - why can't you teach your smart beginners using one of the alternative prelude projects?

Then you've never done this, at least not in combination with the mtl. You need at least two imports to import the generalized mapM_ etc: import Prelude hiding (mapM_) import Data.Foldable (mapM_) With mtl (one of the most used packages in the Haskell ecosystem, I'd guess) you additionally need: import Control.Monad.State hiding (mapM_) import Control.Monad.Reader hiding (mapM_) Etcetera etcetera. It's definitely not impossible, but it's a lot harder than 'just, that you import the first one and not the other'. Another difficulty is that if you make an 'alternative prelude' including the generalized mapM_ etc, you have to use NoImplicitPrelude, whereas if your alternative prelude is just an addition, you can just import it. These are all small things, but they add up if you do day to day Haskell programming. Erik

On Tue, May 21, 2013 at 10:36 PM, Henning Thielemann wrote:

On Tue, 21 May 2013, Erik Hesselink wrote:

...

Then you've never done this, at least not in combination with the mtl. You need at least two imports to import the generalized mapM_ etc:

import Prelude hiding (mapM_) import Data.Foldable (mapM_)

With mtl (one of the most used packages in the Haskell ecosystem, I'd guess) you additionally need:

import Control.Monad.State hiding (mapM_) import Control.Monad.Reader hiding (mapM_)

I answered to this argument to Andreas Abel. I just do not use mtl for this and other purposes. I use transformers.

Then your remark was doubly unfair: you knew about the issues, but chose to ignore/misrepresent them because *you* don't run into them. Erik

El May 21, 2013, a las 8:20 AM, Oliver Charles escribió:

As a Haskell beginner I actually found in confusing that once I'd learnt the prelude functions I had to learn more functions again to get to the generalised functions. I would have rather been taught the general functions in the specific frame of lists, and then show why the type signature is more general than one for lists.

+1! Tom

On 21 May 2013 18:22, Henning Thielemann wrote:

On Tue, 21 May 2013, Carter Schonwald wrote:

...

2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes.

The Haskell beginners I know, even have problems with 'map' and even more 'fold' being higher order functions.

Perhaps such novice programmers should be taught using a Haskell subset or different language, such as Helium or Elm. Conrad.

One potentially palatable option would be to just note that incorporating these into the a Prelude can be done while leaving the haskell98 and haskell2010 packages with the current behavior. Really, it would have to. This means that in the bizarre circumstance that someone relies on the exact current behavior for teaching purposes, there is a path forward for them. -Edward On May 21, 2013, at 11:02 AM, Casey McCann wrote:

On Tue, May 21, 2013 at 6:22 AM, Henning Thielemann wrote:

...

On Tue, 21 May 2013, Carter Schonwald wrote:

...

2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes.

The Haskell beginners I know, even have problems with 'map' and even more 'fold' being higher order functions.

Notwithstanding that anyone having trouble with a monomorphic foldr is unlikely to be significantly worse off with the Data.Foldable version, and notwithstanding also that I've seen redundant monomorphic functions create more confusion than they seem to avoid, the base objection here is and always has been misguided at best.

Being a beginner is by definition an ephemeral state; the entire purpose of being a beginner is to eventually stop being one. Don't design a language (or anything else) around the needs of beginners unless you intend that only beginners will use it, in which case one wonders why they're even bothering.

- C.

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

On Tue, 21 May 2013, Ian Lynagh wrote:

On Tue, May 21, 2013 at 11:20:28AM -0400, Edward Kmett wrote:

...

One potentially palatable option would be to just note that incorporating these into the a Prelude can be done while leaving the haskell98 and haskell2010 packages with the current behavior.

Wherever feasible, any change to Prelude would not be reflected in haskell98:Prelude or haskell2010:Prelude. If we make changes at the same time as splitting base, then i think it makes sense to leave an unchanged Prelude in base too.

I have to say, I find splitting the base package much more important than changing Prelude.

One nice thing about the limited palette of tools we're generally willing to allow ourselves in the base libraries is that it steers us towards a pretty reasonable middle ground. Since MPTCs and fundeps are off the table for the forseeable future in terms of Prelude library design, we're more or less forced into the subset of Haskell that works and infers nicely. Is what Foldable/Traversable allow us to build strictly the most general thing that could be built? No -- but it does tend to run a pretty good balance between rigorous laws, flexibility, ease of understanding, and inference. When I see these pie in the sky options about generalizing everything away almost universally those rely on extensions that frankly don't infer well. Foldable and Traversable do not rise to that level of complexity and can be implemented entirely within a framework we've had fully fleshed out for 15 years. When is it enough to just integrate an improvement and move on? Should we try again at 30 years or do you think someone might have accidentally written another book in the meantime? -Edward On Tue, May 21, 2013 at 4:44 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Tue, 21 May 2013, Casey McCann wrote:

Being a beginner is by definition an ephemeral state; the entire

...

purpose of being a beginner is to eventually stop being one. Don't design a language (or anything else) around the needs of beginners unless you intend that only beginners will use it, in which case one wonders why they're even bothering.

The other way round does not work, too. If you are trying to put the most general (thus most "useful" function) to Prelude, you will find that there will always be more general generalizations. Today you say

mapM_ :: (a -> m b) -> [a] -> m ()

should be replaced by more general

mapM_ :: (a -> m b) -> f a -> m ()

But this is not the most general form. We have discussed several times about generalizing the (), without a conclusion. But maybe some day there might be consensus to generalize the () away ... what will be the next generalization? We may generalize the (->) away. What else?

For me it is perfect to start with something simple in Prelude and build more general functions around it in other modules. This is a scheme that we can manage over time with backwards compatibility.

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

Ay yi yi! A few thoughts on all of this: 1) Rather than guessing how much will or won't break - would some please just run this change (F/T in Prelude) over Hackage and do some analysis and stats? Sure, it doesn't represent all code - but it's a good start. 2) That there are so many Prelude replacements... and that none of them are worth it enough to induce people to add the two lines of code it takes to use 'em.... tells me that they don't have enough value. 3) Stability is very important to adoption of a language. People are very influenced by their first impressions of a system. We seem perilously close to "death by continuous little paper cuts" here: I saw the catch debacle snag tons of people and projects in tiny hiccups. If you were a newcomer to Haskell (experienced engineer or no) and you ran into this, I bet it was a turn off. In generaly I'm against the constant evolution of Haskell. Revising the language every year (or even every two), and revising the core libraries and modules and Prelude piecemeal seem to me like recipes for avoiding success. Now that functional programming is gaining some notice in the wider engineering world, now would be the time to have the most stable, most "always just works", most reliable language of the lot. That probably means stability trumps warts. Not forever, but it means avoiding a constant stream of hiccups. I think we'd be better served by "chunking" this stuff up over several years - and releasing it in well defined sets. 4) My reaction to the "monomorphism helps newbies" argument is always the same: Well then, let's just fix the error messages! - Mark ​

On Wed, May 22, 2013 at 01:52:44PM +0800, John Lato wrote:

Aside from that, how does one run a build over all Hackage?

http://hackage.haskell.org/trac/ghc/wiki/HackageTesting Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

El May 22, 2013, a las 1:12 AM, Mark Lentczner escribió:

Ay yi yi!

A few thoughts on all of this:

1) Rather than guessing how much will or won't break - would some please just run this change (F/T in Prelude) over Hackage and do some analysis and stats? Sure, it doesn't represent all code - but it's a good start.

Agreed!

2) That there are so many Prelude replacements... and that none of them are worth it enough to induce people to add the two lines of code it takes to use 'em.... tells me that they don't have enough value.

Other reasons are a) not widely known - no Haskell book mentions them, and b) introduction of another package dependency (a major concern for me personally)

3) Stability is very important to adoption of a language. People are very influenced by their first impressions of a system. We seem perilously close to "death by continuous little paper cuts" here: I saw the catch debacle snag tons of people and projects in tiny hiccups. If you were a newcomer to Haskell (experienced engineer or no) and you ran into this, I bet it was a turn off.

In generaly I'm against the constant evolution of Haskell. Revising the language every year (or even every two), and revising the core libraries and modules and Prelude piecemeal seem to me like recipes for avoiding success. Now that functional programming is gaining some notice in the wider engineering world, now would be the time to have the most stable, most "always just works", most reliable language of the lot. That probably means stability trumps warts. Not forever, but it means avoiding a constant stream of hiccups.

This is a valid concern, but I can easily imagine the rationale of "functional programming is gaining popularity - don't scare people away now" preventing us from making changes for several years. A "continuous improvement" model of small changes we all adapt to could be less daunting to beginners. Also, the case has been made for beginners, but what about "intermediates"? Trying other data structures will be much less foreign if they've been raised on Foldable and Traversable.

I think we'd be better served by "chunking" this stuff up over several years - and releasing it in well defined sets.

4) My reaction to the "monomorphism helps newbies" argument is always the same: Well then, let's just fix the error messages!

Agreed. Tom

As far as beginners and teaching goes, why don't we have two Preludes? (1) The real (and somewhat scary) Prelude (2) A stripped down, less flexible, but easier to comprehend Prelude The DrRacket (ex DrScheme) people have language levels. We could have library levels. The idea would be that the "SimplePrelude" would only expose a subset of the classes/types/functions of the "real Prelude" and would in many cases only export type instances of the functions in the "real Prelude". For example, map would just be defined for lists in the SimplePrelude, whereas it would be defined for arbitrary functors in the real Prelude. Manuel Henning Thielemann :

On Tue, 21 May 2013, Carter Schonwald wrote:

...

2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes.

The Haskell beginners I know, even have problems with 'map' and even more 'fold' being higher order functions.

Simon Marlow :

On 28/05/13 02:24, Manuel M T Chakravarty wrote:

...

As far as beginners and teaching goes, why don't we have two Preludes?

(1) The real (and somewhat scary) Prelude (2) A stripped down, less flexible, but easier to comprehend Prelude

The DrRacket (ex DrScheme) people have language levels. We could have library levels.

The idea would be that the "SimplePrelude" would only expose a subset of the classes/types/functions of the "real Prelude" and would in many cases only export type instances of the functions in the "real Prelude". For example, map would just be defined for lists in the SimplePrelude, whereas it would be defined for arbitrary functors in the real Prelude.

Indeed. Furthermore, I propose that an import of a module with a "Prelude." prefix automatically turns on NoImplicitPrelude.

import Prelude.Simple

Very nice idea! Manuel

...

Henning Thielemann :

...

On Tue, 21 May 2013, Carter Schonwald wrote:

...

2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes.

The Haskell beginners I know, even have problems with 'map' and even more 'fold' being higher order functions.

_______________________________________________ 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

Indeed. Type annotations, inlining, and writing monomorphic functions are quite handy for making tight inner loops. As are making sure there are no bad branch predictors, that memory locality quality is superb, and that if possible SIMD instructions, and cache hierarchy aware parallelism. At the same time, these are not AND should not be the concerns of normal end user codes. Tuning tight inner loops is a nontrivial task engineering task in any language, providing generic apis by default does not prevent writing monomorphic versions as needed. Unless you have an example where for normal application code there will be a significant constant factor difference in performance with the proposed changes, i don't understand your contention :) Also, for those sorts of problems as you point at, what is an example that can't be resolved with the inlinable + specialize pragmas, that wouldn't otherwise be a problem anyways? Anyways, I do care about performance, but small constant factors are cheaper to fix if need be than are the constant factors in better base api. Anyone who's privy to my work over the past few months know I quite literally spend all my time thinking about memory locality :) cheers -Carter On Sun, May 26, 2013 at 5:21 AM, Malcolm Wallace wrote:

On 21 May 2013, at 06:06, Carter Schonwald wrote:

...

lets see what concerns there are

1) will any code break? Nope! 2) does the change make learning the language more challenging? No.

One concern that is conspicuously missing from your list is

3) performance. Will my code get slower, because it now has many more class dictionaries, requiring new runtime indirections?

I quote from the GHC manual:

"Overloaded functions are not your friend: Haskell's overloading (using type classes) is elegant, neat, etc., etc., but it is death to performance if left to linger in an inner loop."

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