On 3/24/07, Chris Eidhof wrote:

...

Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. I basically agree with a lot of the things you say. The only thing is: it's so convenient to have the Prelude. I can just start writing my haskell programs and don't have to worry about all kinds of imports. And you'll end up being repetitive: you'll import (.) and stuff like that in _every_ file. Yeah, this will definitely be more modular, but if we go for it, it's going to be so much more (tedious) work to create a new program.

The solution is simple: * If there is a "module M where" clause in the beginning of the file, then it's a "proper" module and shouldn't import the Prelude. * If there is no module declaration then it's a "quick'n dirty script" and should have the Prelude implicitly imported. * Interactive interpreters should probably import the Prelude. That should take of most issues. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

Chris Eidhof writes:

On Mar 24, 2007, at 2:36 AM, Sebastian Sylvan wrote:

...

The solution is simple:

* If there is a "module M where" clause in the beginning of the file, then it's a "proper" module and shouldn't import the Prelude. * If there is no module declaration then it's a "quick'n dirty script" and should have the Prelude implicitly imported. * Interactive interpreters should probably import the Prelude.

So if I'm writing a script, which has been working, then import Control.Monad, it all suddenly stops working?

No, that's an import declaration, not a module declaration. So far, this is my favorite proposal, but I'm not sure it's better than leaving things the way they are. There's a lot of useful stuff in the Prelude, so the typical usage is likely to be "import Prelude hiding (...)", which you can do right now. On the other hand, making this like this explicit seems consistent with Haskell's traditions. -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"

On Sat, 2007-03-24 at 11:53 +0000, Neil Mitchell wrote:

...

This is a highly non-academic concern. Many widely used libraries, such as Parsec, operate only on lists and not the newer and more efficient sequence types, such as bytestrings.

Lists in Haskell are the nicest data structure, they work most naturally with the language. There is a reason that lists is the default.

In particular lists are often used as a control structure whereas most other sequence data types are really only data structures. Duncan

G'day all. Quoting Sven Panne :

Even though I think that the current Prelude is far from perfect, one should not forget that is a very solid foundation of a "common language": If one sees e.g. '(.)' or 'map', it is immediately clear to everybody what this means, [...]

Unless you import Data.Map, of course. Cheers, Andrew Bromage

G'day all. Quoting Jason Creighton :

Wouldn't this be a non-issue if the "map" in Prelude was fmap?

It would be a non-issue if a number of things were different, such as if Data.Map were a Functor and "map" was the Functor map instead of the list map. Either way, it highlights at least two of the original complaints about the Prelude: 1. It gobbles up names that people want to use. 2. It's not generic enough. Incidentally, I disagree with one of the sentences in the OP: "The Prelude was designed by extremely smart people and was considered close to perfect at the time." The first half is, at best, partly true. Don't get me wrong, everyone who has added stuff to the Prelude over the years was, I have no doubt, individually smart. But it would be only partly correct to call it "designed". Rather, it was originally consolidated from all of the Miranda-work-alikes of the late 80s, then gradually added to as features (e.g. constructor classes) were addedto the language. As such, the Prelude is not a well-designed coherent whole, but rather an eclectic mix of Miranda-isms and Gofer-isms. I understand that we do need a common base language of functions, and calling it "Prelude" is as good as ny other. But we don't miss complex numbers being in the Prelude, and I suspect we wouldn't miss other stuff getting moved out into modules either. Cheers, Andrew Bromage

I don't think he would be confused with functor in SML. Call functors static classes and you cut the language from intuition. In such language anybody can express anything. But to arrive at something one needs intuition! Now, what mathematically blind programmers can gain from learning about monad if they are taught that functor is a class? -Andrzej

Hi

At any rate, since Map is a Functor, I vote for Data.Map.map to be deleted. Any disagreements before I submit the ticket?

Yes. It will break 100's of applications. If you are going to do this, you probably need to propose it be marked as depreciated, and then deleted sometime years into the future. Thanks Neil

I can contribute a few. On Mar 26, 2007, at 02:14 , ajb@spamcop.net wrote:

G'day all.

Quoting Neil Mitchell :

...

Yes. It will break 100's of applications.

That sounds like a challenge! Find me 100 applications that use Data.Map.map and I will eat crow.

Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

ajb@spamcop.net wrote:

G'day all.

Quoting Neil Mitchell :

...

Yes. It will break 100's of applications.

That sounds like a challenge! Find me 100 applications that use Data.Map.map and I will eat crow.

Well, I haven't written 100s of applications (yet), but I get hits on 'map' in each and every one of them. Of course, wouldn't map = fmap solve the problem? Dave

Hi

...

Yes. It will break 100's of applications.

That sounds like a challenge! Find me 100 applications that use Data.Map.map and I will eat crow.

http://www.google.com/codesearch?hl=en&q=+lang:haskell+Map.map&start=10&sa=N Since most people import qualified Data.Map as Map. Not all of those are real hits, but it looks like 100 is a reasonable goal. Thanks Neil

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David House wrote:

On 24/03/07, Stefan O'Rear wrote:

...

This is a ranty request for comments, and the more replies the better.

Without responding to any particular comment, my opinion is that we should have a minimal Prelude with functions like (.) that couldn't be reasonably redefined in any function.

I can recall two variations on (.)... Strict composition, perhaps (.!), that is somehow strict in the functions that are its arguments. Unicode composition, i.e. use the Unicode character for function composition (?) instead of the overloaded (with module system syntax) "." symbol Not that these are worthy alternatives for our Prelude, just reasons that I don't entirely like the idea of any implicitly included prelude. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGD57RHgcxvIWYTTURAjwuAKCeX5KJ+511lctcC5EXJ+7kYtsNqACfd/GS PSteOUuiJqYAaaJBwiblaso= =U/j/ -----END PGP SIGNATURE-----

[reply-to set; dropping libraries] On Sun, Mar 25, 2007 at 04:33:51PM +0100, David House wrote:

On 25/03/07, Ian Lynagh wrote:

...

I've submitted:

http://hackage.haskell.org/trac/haskell-prime/ticket/124

which I hope covers the essence of the result of this thread.

I'd hate to have to import things like Data.Function for such trivial functions as (.) and ($)

You wouldn't have to import a number of different modules like Data.Function, you could just import Prelude. The only difference is that, for Real modules, you explicitly say that you want the Prelude, rather than sometimes needing magic like import Prelude () Thanks Ian

On 3/25/07, David House wrote:

On 25/03/07, Ian Lynagh wrote:

...

I've submitted:

http://hackage.haskell.org/trac/haskell-prime/ticket/124

which I hope covers the essence of the result of this thread.

I'd hate to have to import things like Data.Function for such trivial functions as (.) and ($), which are so often used that they become almost like control structures and keywords in themselves. What did people think of my idea of a stripped down prelude containing primarily the functions like (.) and ($)? Here'd be my list:

1. Almost like control structures otherwise (.) flip ($)

2. To make including literals sane Char String Int Integer Num(..)

3. Other basic functions Eq(..) Ord((<), (>), (<=), (>=)) Show(show)

4. Miscellaneous id const undefined

Of course, the precise details would be debateable.

I think I like this proposal. Perhaps without 2 though (unless Num and String gets some attention). I'm not sure the "not automatically imported if proper module" rule is needed if the Prelude gets stripped down a bit, but I wouldn't mind it (it makes sense to make imports explicit in "proper" modules). So to summarize what I perceive to be the issues: * Do we want a new Prelude, or just hide the existing one? (I want a new, stripped down version) * Should this new Prelude be automatically included always, or should it be hidden in "proper modules" (I'm ambivalent). * Should there be a larger backwards compatible Prelude (I think Yes) * Shold this larger Prelude be implicitly imported for non-proper modules? (I think no, it should always be explicitly imported, perhaps through command line options) With regards to the first point, I think it's a misstake to just have "Large Prelude which is not implicitly imported" because everytime you need (.) or ($) people would probably just "import Prelude" and then you're stuck with the old problem again. So I do think stripping down the Prelude is essential. I think this is a separate issue that can be agreed upon regardless of the issue of wether it should be implicitly imported or not. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

On 28/03/07, Simon Marlow wrote:

I support both reducing the prelude to just a few commonly used combinators, and requiring an explicit import Prelude.

Just to clear things up: would you need to do an import Prelude to get at these few commonly used combinators, or would the import pull in the 'wider' Prelude, with a more expansive selection, more akin to the current Prelude? -- -David House, dmhouse@gmail.com