Why the Prelude must die

[Stefan O'Rear]

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

1. Namespace pollution

The Prelude uses many simple and obvious names.  Most programs don't
use the whole Prelude, so names that aren't needed take up namespace
with no benefit.

2. Monomorphism

The Prelude defines many data types (e.g Lists), and operations on
these types.  Because the Prelude is imported automatically,
programmers are encouraged to write their programs in terms of
non-overloaded operators.  These programs then fail to generalize.

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.

3. Supports obsolete programming styles

The Prelude uses, and by means of type classes encourages, obsolete
and naive programming styles.  By providing short functions such as
nub automatically while forcing imports to use sets, the Prelude
insidiously motivates programmers to treat lists as if they were sets,
maps, etc.  This makes Haskell programs even slower than the inherent
highlevelness of laziness requires; real programs use nub and pay
dearly.

More damagingly, the Prelude encourages programmers to use
backtracking parsers.  Moore's law can save you from nub, but it will
never clarify "Prelude.read: no parse".

4. Stagnation

Because every program uses the Prelude, every program depends on the
Prelude.  Nobody will willingly propose to alter it.  (This is of
course Bad; I hope Haskell' will take the fleeting opportunity to
break to loop)

5. Inflexibility

Because of Haskell's early binding, the Prelude always uses the
implementation of modules that exists where the Prelude was compiled.
You cannot replace modules with better ones.

6. Dependency

Because every module imports the Prelude every module that the Prelude
depends on, mutually depends with the Prelude.  This creates huge
dependency groups and general nightmares for library maintainers.

7. Monolithicity

Every module the Prelude uses MUST be in base.  Even if packages could
be mutually recursive, it would be very difficult to upgrade any of
the Prelude's codependents.

8. Monolithic itself

Because the Prelude handles virtually everything, it is very large and
cannot be upgraded or replaced piecemeal.  Old and new prelude parts
cannot coexist.

9. One-size-fits-all-ism

Because the Prelude must satisfy everyone, it cannot be powerful,
because doing so would harm error messages.  Many desirable features
of Haskell, such as overloaded map, have been abandoned because the
Prelude needed to provide crutches for newbies.

10. Portability

Because the Prelude must be available everywhere, it is forced to use
only least-common-denominator features in its interface.  Monad and
Functor use constructor classes, even though MPTC/FD is usefully far
more flexible.  The Class_system_extension_proposal, while IMO
extremely well designed and capable of alleviating most of our class
hierarchy woes, cannot be adopted.

11. Committeeism

Because the Prelude has such a wide audience, a strong committee
effect exists on any change to it.  This is the worst kind of
committeeism, and impedes real progress while polluting the Prelude
with little-used features such as fail in Monad (as opposed to
MonadZero) and until.

12. There is no escape

Any technical defect in Map could be fixed by someone writing a better
Map; this has happened, and the result has been accepted.  Defects in
the PackedString library have been fixed, with the creation and
adoption of ByteString.  Defects in System.Time have been fixed, by
the creation and adoption of Data.Time.  Ditto for Binary and Arrays
and Network and Regex.  But this will never happen for the Prelude.  A
replacement Prelude cannot be adopted because it is so easy to take
the implicit import of the default one.  Nobody will go out of their
way to 'import Prelude() ; import FixedPrelude'.  Psychology trumps
engineering.

13. There can be no escape

The Prelude was designed by extremely smart people and was considered
close to perfect at the time.  It is almost universally hated now.
Even if all the issues I describe could be fixed (which I consider
unlikely), the Prelude will almost certainly be hated just as
universally five years hence.

14. My future

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.

Stefan
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Donald Bruce Stewart]

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

Use -fno-implicit-prelude and roll your own Prelude. Stick it on hackage
and everyone can use it.

-- Don
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Chris Eidhof]

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

-chris
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sebastian Sylvan]

On 3/24/07, Chris Eidhof <chris@...> 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
[phone]
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[ndmitchell]

Hi

Reducing to just haskell-cafe - since this isn't yet a concrete
proposal - more just a discussion.

> 1. Namespace pollution

Do you want to overload (.) ? I think its good that some names mean
standard things. Maybe not as many as the prelude, but some standard
things are good.


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


> 3. Supports obsolete programming styles

Niggle: nub isn't in Prelude, it's Data.List

> More damagingly, the Prelude encourages programmers to use
> backtracking parsers.  Moore's law can save you from nub, but it will
> never clarify "Prelude.read: no parse".

This is very bad!

> 5. Inflexibility
>
> Because of Haskell's early binding, the Prelude always uses the
> implementation of modules that exists where the Prelude was compiled.
> You cannot replace modules with better ones.

I think this is a good thing - I can imagine people changing map to
also do a reverse, then changing it retroactively in an existing
program/library. They should at least be forced to recompile.


> 6. Dependency

Could not agree more! If additionally your compiler is written in a
silly way, you can make this problem 100 times worse for yourself.

> 13. There can be no escape

I still like the Prelude.

> 14. My future
>
> 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 would then provide "Common" or something, which just imported and
exported Control.Function/Data.List and the other common modules. This
would probably be better for scripts (I often end up importing
Data.List, System.Directory, System.Process), and would make larger
programs more explicit.

If Common was provided as a replacement, which was more general than
the Prelude, then you could do that easily. With a tiny bit of work I
think you could replicate Prelude and add flags as required.

Of course, I think technically this would be a lot of work - just
fighting with dependencies, bugs, make systems, silly compilers etc.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Chris Eidhof]

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

> On 3/24/07, Chris Eidhof <chris@...> 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.

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

I also think that you want to minimize the differences between an  
interpreted (interactive) version and a compiled version. It would be  
very weird for first-time users if their scripts work in ghci but  
break when they compile them.

I'm sorry for being so negative. I like the idea, but I don't like it  
from a newbie-standpoint. The thing is: this is mostly handy for  
power-users, maybe we should do it for power-users only? We can still  
change the prelude to have no more code in there, but make it only a  
bunch of imports?

-chris
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sven Panne]

On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
> 1. Namespace pollution
>
> The Prelude uses many simple and obvious names.  Most programs don't
> use the whole Prelude, so names that aren't needed take up namespace
> with no benefit. [...]

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, without having to scan through (perhaps long) import lists. Of course
one could hide some parts of the Prelude etc., but I think in the long run
this only leads to confusion. Redefining common things, heavy use of tons of
self-defined operators etc. all make maintenance much harder.

Try reading Lisp code with heavy use of macros or C++ code with tons of
overloadings. This is more like Sudoku solving than anything else, because
there is no "common language" between the author and the reader anymore.

And taking away the prelude is a little bit like taking
away 'int', 'double', 'for', 'while' etc. from the C programmer...

> 11. Committeeism
>
> Because the Prelude has such a wide audience, a strong committee
> effect exists on any change to it.  This is the worst kind of
> committeeism, and impedes real progress while polluting the Prelude
> with little-used features such as fail in Monad (as opposed to
> MonadZero) and until.

Depending on your viewpoint, you can see this as a plus. Everybody agrees that
finalizers are evil, but propose the removal of that method from
java.lang.Object to the Java people. :-)

My proposal would be to incrementally improve the Prelude, modularize it a bit
more, fix the Num hierarchy, but basically leave it as it is.

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

[David House]

On 24/03/07, Stefan O'Rear <stefanor@...> 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. Most of the list functions
should have to be imported, to encourage people to use a Map or Array
and so on. Read should be in Text.Read to encourage people to use
Parsec and so on.

I wouldn't necessarily be against a minimal Prelude/expanded Prelude
split determined by a 'module M where' declaration, as suggested by
Sebastian.

--
-David House, dmhouse@...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[ajb-2]

G'day all.

Quoting Sven Panne <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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Vivian McPhail]

I agree with Sven, but...

What I want to push is a 'mathematically sound' numeric prelude.  A proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical classes.  It would be edifying
to the student who discovered that the particular data type he is using is
an inhabitant of a known class and can thus take advantage of known
properties, presupplied as class methods.  Reasoning and communication about
programs, data types, and functions would be enhanced.

[Conjecture 1 (2007). Haskell Mathematical Prelude and Mathematicians] If
Haskell had a mathematically sound prelude then more mathematicians would
use Haskell.

Cheers,

Vivian

>
> Message: 1
> Date: Sat, 24 Mar 2007 17:56:11 +0100
> From: Sven Panne <sven.panne@...>
> Subject: Re: [Haskell-cafe] Why the Prelude must die
> To: haskell-cafe@...
> Cc: libraries@...
> Message-ID: <200703241756.11121.sven.panne@...>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
> > 1. Namespace pollution
> >
> > The Prelude uses many simple and obvious names.  Most
> programs don't
> > use the whole Prelude, so names that aren't needed take up
> namespace
> > with no benefit. [...]
>
> 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,
> without having to scan through (perhaps long) import lists.
> Of course one could hide some parts of the Prelude etc., but
> I think in the long run this only leads to confusion.
> Redefining common things, heavy use of tons of self-defined
> operators etc. all make maintenance much harder.
>
> Try reading Lisp code with heavy use of macros or C++ code
> with tons of overloadings. This is more like Sudoku solving
> than anything else, because there is no "common language"
> between the author and the reader anymore.
>
> And taking away the prelude is a little bit like taking away
> 'int', 'double', 'for', 'while' etc. from the C programmer...
>
> > 11. Committeeism
> >
> > Because the Prelude has such a wide audience, a strong committee
> > effect exists on any change to it.  This is the worst kind of
> > committeeism, and impedes real progress while polluting the Prelude
> > with little-used features such as fail in Monad (as opposed to
> > MonadZero) and until.
>
> Depending on your viewpoint, you can see this as a plus.
> Everybody agrees that finalizers are evil, but propose the
> removal of that method from java.lang.Object to the Java people. :-)
>
> My proposal would be to incrementally improve the Prelude,
> modularize it a bit more, fix the Num hierarchy, but
> basically leave it as it is.
>
> Cheers,
>    S.
>
>

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

[David Menendez]

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 <zednenem@...> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jason Creighton]

On Sat, Mar 24, 2007 at 10:08:48PM -0400, ajb@... wrote:

> G'day all.
>
> Quoting Sven Panne <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.

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

Jason Creighton
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Duncan Coutts]

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

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

[ajb-2]

G'day all.

Quoting Jason Creighton <jcreigh@...>:

> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ivan Lazar Miljenovic]

On Sun, 2007-03-25 at 14:14 +1200, Vivian McPhail wrote:
>
> [Conjecture 1 (2007). Haskell Mathematical Prelude and Mathematicians] If
> Haskell had a mathematically sound prelude then more mathematicians would
> use Haskell.

I agree, even though I've only been using Haskell for a few months.
Especially if matrix functions were included.  Then you can also get
category theorists using a practical implementation of some of their
theories to solve problems ;-)


--
Ivan Lazar Miljenovic


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

[sloan-7]

On 3/24/07, Vivian McPhail <vivian.mcphail@...> wrote:

I agree with Sven, but...

What I want to push is a 'mathematically sound' numeric prelude.  A proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical classes.  It would be edifying
to the student who discovered that the particular data type he is using is
an inhabitant of a known class and can thus take advantage of known
properties, presupplied as class methods.  Reasoning and communication about
programs, data types, and functions would be enhanced.

One problem with that is that the instances are often times not mathematically sound - Int and Double certainly aren't.

Anyway, I agree with the general gist of this idea. However, I think rather than the Prelude, we should just be an interface to the internal stuff, a 'Builtin' module. Actually, there could still be a prelude - it would contain all the common imports (to maintain our decent scores in golf competitions :) ).

I also like the idea that the addition of a module line would remove the implicit prelude import - the source code has become 'proper'.  Before the module line, the programmer is probably in quick-hack/script mode.

Numeric prelude-ness would be good.  This brings up an issue - would the numeric classes need to be included/imported in Builtin?  To avoid this, I think a bit of evillness (depending on your perspective, i suppose) is necessary - builtin functions would be stuff like AddInts and AddDoubles, not (+). The numeric stuff that provides the classes would also provide instances to wrap the builtin stuff.

Hmm, just realized that PreludeBuiltin already exists...  Ahwell, I think the renaming is a good idea - classes should not be involved in the builtins.

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

[Claus Reinke]

why do people insist that what they don't need has no right to live?

also, there doesn't seem to be anything left in the Prelude itself, it just re-exports
everything from one particular collection of modules. so the Prelude isn't really a useful
target for complaints anymore, only the implicit import Prelude and the organisation of
the base package are.

authors and readers of older haskell books, as well as other programmers caring about
stability will want -package haskell98 to provide the one implicitly imported Prelude.

for those about to rely on -package haskell-prime, things are still open, while those
relying on -package base will want clear documentation on which versions of base
are backwards-compatible with all those haskell programs currently out there relying
on an implicit Prelude, and which are not.

> 1. Namespace pollution
> 2. Monomorphism
> 3. Supports obsolete programming styles

these points could be addressed by requiring explicit import Prelude, starting from
packages haskell-prime and the next version of base.

> 4. Stagnation
> 5. Inflexibility
> 6. Dependency
> 7. Monolithicity

these points seem to apply to package base rather than just the Prelude.

> 8. Monolithic itself
> 9. One-size-fits-all-ism
> 10. Portability
> 11. Committeeism
> 12. There is no escape
> 13. There can be no escape

once most code-bases have shifted to explicit import Prelude, it will become easier
to replace that with import MyFavouritePrelude, where appropriate. that will also add
more force to the recommendation to be more specific about imports, eg, import
Data.List instead of import Prelude. once the Prelude is less attractive as an exaggerated
swiss army knife style dumping ground for and source of definitions, the focus will perhaps
shift to the separate modules it re-exports.

i could well imagine different projects and books defining their own Prelude, re-exporting
all those and only those modules needed or appropriate for their code. for instance, a
haskell programming tutorial will have different needs (only basics) than a graphics tutorial
(gui libs) than a book (functions provided in or disscussed in the book) than a script
(System.Environment, System.Directory,..) than a <insert your current project here>
(<things you import in every one of your modules make up your project's prelude>).

} * 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.

agreed, at least not implicitly, and with the caveats on backwards-compatibility
mentioned above.

} * If there is no module declaration then it's a "quick'n dirty script"
} and should have the Prelude implicitly imported.

which Prelude, though? haskell98? haskell-prime? current-base? shell-scripting?

} * Interactive interpreters should probably import the Prelude.

which makes sense for playing around, but not for interacting with real modules.

------

i suggest to make 'import Prelude' explicit for future versions of haskell (haskell-prime,
base-<next-version>), and to have a standard flag for adding imports to non-explicit
interpreter/runhaskell-sessions. starting an interactive system without explicitly loaded
modules, and without --implicit-import flags, needs to load some default prelude, but
should make it obvious that there is an implicit default import going on, and explain
how to reproduce that import in proper modules (by giving a message

    "no modules loaded - loading default Prelude: <which>"

that message should probably not be a warning, to avoid confusing beginners;-).

the scrap module (no module header) could be handled like any session without
explicitly loaded modules, so it will either follow the --implicit-import flags, or
implicitly import the default prelude if there are no such flags (perhaps we should
start distinguishing scrap modules from an implicit Main?).

the default prelude would depend on the version of haskell selected (haskell98,
haskell-prime, haskell-current), and it would be easy to add runhaskell-script
(like runhaskell, but with a different implicit prelude, more suited to scripting).

claus

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

[Jacques Carette]

Vivian McPhail wrote:
> What I want to push is a 'mathematically sound' numeric prelude.  A proper
> numerical prelude should have bona fide mathematical obects like groups,
> rings, and fields underlying common numerical classes.  It would be edifying
> to the student who discovered that the particular data type he is using is
> an inhabitant of a known class and can thus take advantage of known
> properties, presupplied as class methods.  Reasoning and communication about
> programs, data types, and functions would be enhanced.
>  
Yes, except that there are not as many groups, rings and fields out
there as you think.  For one thing, Float and Double are not in any of
those.  The best you can do with Float and Double is
NonAssociativeAlgebra, which is unlikely to be 'edifying'.  At least
Integer is a proper ring.  There is only one field that I am aware of in
Haskell (Rational Integer).  [Which is sad since Z_p is so easy to code
up, and generally extremely useful].

Some classes would become even more important: monoid, groupoid,
semi-group, loop (semi-group with identity), etc.  But all of those are,
to the average programmer (and many a mathematician), just as scary as
Monad.

And personally, the place my semi-groups show up are not in my
data-types, but in my *types*.


Jacques
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Benja Fallenstein]

Hi,

(new here)

2007/3/25, Jacques Carette <carette@...>:
> Some classes would become even more important: monoid, groupoid,
> semi-group, loop (semi-group with identity), etc.  But all of those are,
> to the average programmer (and many a mathematician), just as scary as
> Monad.

Of course, when you get that general, you start having the problem
that many types can be made into these structures in more than one
way. Even the current Monoid class has that problem, even though it
has some ties to a particular application (the Writer monad and stuff
similar to it -- as reflected in the 'mappend' and 'mconcat' names).

You can have newtype wrappers, but that's at least somewhat annoying :-)

I'd like to see these classes in the standard library, but I'm not
sure at this point whether they are useful enough to have in the
prelude, as long as they're not at least losely to a specific
application (Field -> numbers; Monoid -> collecting results; Monad ->
imperative computations).

- Benja
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ian Lynagh]

I've submitted:

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

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


Thanks
Ian

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