Why the Prelude must die

[Simon Marlow-5]

I support both reducing the prelude to just a few commonly used combinators, and
  requiring an explicit import Prelude.  In response to a couple of Stefan's points:

Stefan O'Rear wrote:

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

Not a problem in practice, for GHC at least: all modules below the Prelude use
-fno-implicit-prelude, there's no recursive dependency.  Also, if the Prelude
were smaller, it would be much lower in the dependency tree which would make
life easier.

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

Not necessarily - the Prelude itself doesn't have to be in base.  If we split up
base, then Prelude would likely have to be in a separate package.  Haskell' will
need a separate Prelude, so the Haskell 98 Prelude will need to move to the
haskell98 package.

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

[Andrzej Jaworski]

On blessed Wed Mar 28 05:52:03 EDT 2007 Simon Marlow wrote:

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

So YOU are the GOD's angle with the sword!

And thus we leave the orchard for a battlefield. I really like this:-)

Holy regards,
-Andrzej

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

[David House]

On 28/03/07, Simon Marlow <simonmarhaskell@...> 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@...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[David House]

On 28/03/07, Jeffrey Yasskin <jyasskin@...> wrote:
> I would vote for a Combinators module with the most important
> combinators, and a somewhat larger Prelude to support quick scripts
> and demonstrations.

I'd hate to have to import a module just to get at ($). Like I've
mentioned before, some combinators are so ubiqutos they're almost like
syntax. Seeing as the actual syntax will always be in scope, these
common combinators would also have to be in scope all the time, which
means placing them in the narrowed Prelude.

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

[Benjamin Franksen]

Nicolas Frisby wrote:
> Regarding type variable naming, a few of my more hardware minded
> friends I've asked to try Haskell often tease me about the opaque type
> variable names in the Prelude--it seems greater consideration of type
> variable names in the Prelude might behoove new users.

I think that single letter names are very a good idea for most of the things
in the Prelude. 'a', 'b' etc. are good for very general things like the
basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc).
I also like the 'm' for Monads of all kinds, but I would suggest to
use 'mt' for monad transformers. For collections I think 'c' is nice
and 'k' for keys seems to be sort of standard, but I would like to propose
using 'e' as generic name for elements of collections, if there are more
element types, then 'e1', e2' etc.

There are more complicated cases where a multi-letter name seems apropriate,
but there appear to me none of them in the Prelude.

Cheers
Ben

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

[Neil Mitchell]

Hi

> > Regarding type variable naming, a few of my more hardware minded
> > friends I've asked to try Haskell often tease me about the opaque type
> > variable names in the Prelude--it seems greater consideration of type
> > variable names in the Prelude might behoove new users.
>
> I think that single letter names are very a good idea for most of the things
> in the Prelude. 'a', 'b' etc. are good for very general things like the
> basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc).
> I also like the 'm' for Monads of all kinds, but I would suggest to
> use 'mt' for monad transformers. For collections I think 'c' is nice
> and 'k' for keys seems to be sort of standard, but I would like to propose
> using 'e' as generic name for elements of collections, if there are more
> element types, then 'e1', e2' etc.

Looking through the Hoogle logs, if people search for a multi-letter
type name, they are usually getting the wrong end of the stick. People
often search for:

char -> bool

I don't think there is anything wrong with single letter type names,
unless you are making your types too complex.

Thanks

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

[Benjamin Franksen]

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

Int is algebraically sound as a factor ring Z/nZ with n=2**k, k the number
of bits (which could be implementation defined). Unfortunately the order
inherited from Integer is not compatible with the algebra...

Cheers
Ben

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

[Isaac Dupree]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David House wrote:
> 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.

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

[jasonm]

Jacques Carette wrote:

> perhaps i was mistaken in thinking that there is a group of
> math-interested
> haskellers out there discussing, developing, and documenting the area? or
> perhaps that group needs introductory tutorials presenting its work?
My guess is that there are a number of people "waiting in the wings",
waiting for a critical mass of features to show up before really diving
in.  See
http://www.cas.mcmaster.ca/plmms07/
for my reasons for being both interested and wary).

Probably the simplest test case is the difficulties that people are
(still) encountering doing matrix/vector algebra in Haskell.  One either
quickly encounters efficiency issues (although PArr might help), or
typing issues (though many tricks are known, but not necessarily
simple).  Blitz++ and the STL contributed heavily to C++ being taken
seriously by people in the scientific computation community.  Haskell
has even more _potential_, but it is definitely unrealised potential.

I am one of those mathematicians "waiting in the wings."  Haskell looked
very appealing at first, and the type system seems perfect, especially for
things like multilinear algebra where currying and duality is fundamental.
I too was put off by the Num issues though--strange mixture of sophisticated
category theory and lack of a sensible hierarchy of algebraic objects.

However, I've decided I'm more interested in helping to fix it than wait;
so count me in on an effort to make Haskell more mathematical.  For me that
probably starts with the semigroup/group/ring setup, and good
arbitrary-precision as well as approximate linear algebra support.

[Bryan Burgers]

> Jacques Carette wrote:
> >
> >> perhaps i was mistaken in thinking that there is a group of
> >> math-interested
> >> haskellers out there discussing, developing, and documenting the area? or
> >> perhaps that group needs introductory tutorials presenting its work?
> > My guess is that there are a number of people "waiting in the wings",
> > waiting for a critical mass of features to show up before really diving
> > in.  See
> > http://www.cas.mcmaster.ca/plmms07/
> > for my reasons for being both interested and wary).
> >
> > Probably the simplest test case is the difficulties that people are
> > (still) encountering doing matrix/vector algebra in Haskell.  One either
> > quickly encounters efficiency issues (although PArr might help), or
> > typing issues (though many tricks are known, but not necessarily
> > simple).  Blitz++ and the STL contributed heavily to C++ being taken
> > seriously by people in the scientific computation community.  Haskell
> > has even more _potential_, but it is definitely unrealised potential.
> >
>
> I am one of those mathematicians "waiting in the wings."  Haskell looked
> very appealing at first, and the type system seems perfect, especially for
> things like multilinear algebra where currying and duality is fundamental.
> I too was put off by the Num issues though--strange mixture of sophisticated
> category theory and lack of a sensible hierarchy of algebraic objects.
>
> However, I've decided I'm more interested in helping to fix it than wait;
> so count me in on an effort to make Haskell more mathematical.  For me that
> probably starts with the semigroup/group/ring setup, and good
> arbitrary-precision as well as approximate linear algebra support.

I've been watching this thread for quite a while now, and it seems to
me that there is quite a bit of interest in at least working on a new
Prelude. I've also noticed a 'The Other Prelude' page on the wiki
[http://haskell.org/haskellwiki/The_Other_Prelude] and they seem to
have a start on this. So it seems that we should actually start this,
because people will contribute. Can somebody with good Cabal skills
and maybe access to darcs.haskell.org start a new library for people
to start patching?

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

[Andrzej Jaworski]

> I too was put off by the Num issues though--strange mixture of sophisticated
> category theory and lack of a sensible hierarchy of algebraic objects.

Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic
function) before cleaning up the type-related mess?
See: http://citeseer.ist.psu.edu/269479.html

> so count me in on an effort to make Haskell more mathematical.  For me that
> probably starts with the semigroup/group/ring setup, and good
> arbitrary-precision as well as approximate linear algebra support.

I agree: semigoups like lattices are everywhere.
Then there could be a uniform treatment of linear algebra, polynomial equations, operator
algebra, etc. So, perhaps haste is not a good advice here?

-Andrzej

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

[R Hayes]

Wouldn't this be a good discussion for the Haskell Prime List?

Reilly Hayes

[phone] (office)

[phone] (mobile)

rfh@...

On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote:

I too was put off by the Num issues though--strange mixture of sophisticated

category theory and lack of a sensible hierarchy of algebraic objects.

Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic

function) before cleaning up the type-related mess?

See: http://citeseer.ist.psu.edu/269479.html

so count me in on an effort to make Haskell more mathematical.  For me that

probably starts with the semigroup/group/ring setup, and good

arbitrary-precision as well as approximate linear algebra support.

I agree: semigoups like lattices are everywhere.

Then there could be a uniform treatment of linear algebra, polynomial equations, operator

algebra, etc. So, perhaps haste is not a good advice here?

-Andrzej

_______________________________________________

Haskell-Cafe mailing list

Haskell-Cafe@...

http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Henning Thielemann]

On Mon, 2 Apr 2007, jasonm wrote:

> Jacques Carette wrote:
> >
> >> perhaps i was mistaken in thinking that there is a group of
> >> math-interested
> >> haskellers out there discussing, developing, and documenting the area? or
> >> perhaps that group needs introductory tutorials presenting its work?
> > My guess is that there are a number of people "waiting in the wings",
> > waiting for a critical mass of features to show up before really diving
> > in.  See
> > http://www.cas.mcmaster.ca/plmms07/
> > for my reasons for being both interested and wary).
> >
> > Probably the simplest test case is the difficulties that people are
> > (still) encountering doing matrix/vector algebra in Haskell.  One either
> > quickly encounters efficiency issues (although PArr might help), or
> > typing issues (though many tricks are known, but not necessarily
> > simple).  Blitz++ and the STL contributed heavily to C++ being taken
> > seriously by people in the scientific computation community.  Haskell
> > has even more _potential_, but it is definitely unrealised potential.
>
> I am one of those mathematicians "waiting in the wings."  Haskell looked
> very appealing at first, and the type system seems perfect, especially for
> things like multilinear algebra where currying and duality is fundamental.
> I too was put off by the Num issues though--strange mixture of sophisticated
> category theory and lack of a sensible hierarchy of algebraic objects.
>
> However, I've decided I'm more interested in helping to fix it than wait;
> so count me in on an effort to make Haskell more mathematical.  For me that
> probably starts with the semigroup/group/ring setup, and good
> arbitrary-precision as well as approximate linear algebra support.

NumericPrelude popped up in this thread earlier. Is this the starting
point you are after?
 http://darcs.haskell.org/numericprelude/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[jasonm]

NumericPrelude does seem like a good starting point for discussion and
addition.  Is it still being actively developed, and what are the
goals there?

On 4/3/07, Henning Thielemann <lemming@...> wrote:

>
> On Mon, 2 Apr 2007, jasonm wrote:
>
> > Jacques Carette wrote:
> > >
> > >> perhaps i was mistaken in thinking that there is a group of
> > >> math-interested
> > >> haskellers out there discussing, developing, and documenting the area? or
> > >> perhaps that group needs introductory tutorials presenting its work?
> > > My guess is that there are a number of people "waiting in the wings",
> > > waiting for a critical mass of features to show up before really diving
> > > in.  See
> > > http://www.cas.mcmaster.ca/plmms07/
> > > for my reasons for being both interested and wary).
> > >
> > > Probably the simplest test case is the difficulties that people are
> > > (still) encountering doing matrix/vector algebra in Haskell.  One either
> > > quickly encounters efficiency issues (although PArr might help), or
> > > typing issues (though many tricks are known, but not necessarily
> > > simple).  Blitz++ and the STL contributed heavily to C++ being taken
> > > seriously by people in the scientific computation community.  Haskell
> > > has even more _potential_, but it is definitely unrealised potential.
> >
> > I am one of those mathematicians "waiting in the wings."  Haskell looked
> > very appealing at first, and the type system seems perfect, especially for
> > things like multilinear algebra where currying and duality is fundamental.
> > I too was put off by the Num issues though--strange mixture of sophisticated
> > category theory and lack of a sensible hierarchy of algebraic objects.
> >
> > However, I've decided I'm more interested in helping to fix it than wait;
> > so count me in on an effort to make Haskell more mathematical.  For me that
> > probably starts with the semigroup/group/ring setup, and good
> > arbitrary-precision as well as approximate linear algebra support.
>
> NumericPrelude popped up in this thread earlier. Is this the starting
> point you are after?
>  http://darcs.haskell.org/numericprelude/
>

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

[Henning Thielemann]

On Tue, 3 Apr 2007, Jason Morton wrote:

> NumericPrelude does seem like a good starting point for discussion and
> addition.  Is it still being actively developed,

slowly but actively

> and what are the goals there?

A more sophisticated numeric type class hierarchy. However it contains
also some algorithms, because we have to test if the hierarchy indeed
works.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe