Why the Prelude must die

[Claus Reinke]

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

as long as those concepts, like monads, are clearly defined, consistent, and
have practical uses that directly correspond to those concepts and fulfill the
laws associated with them, that should not be a hindrance.. ;)

ok, tongue out of cheek again, someone would need to investigate the
particular shape in which such abstract concepts would be most useful
(which may or may not be the same shape best known in maths, see
Monad, Monoid, Applicative, Arrow,..), and how those shapes are best
expressed within the programming language abilities. and then, of course,
someone would need to write code and tutorials.

i know there has been a lot more than just talk wrt numeric preludes for
haskell, but just now, it took me a while to find the main incumbents, and
i could easily have been put off track by other mathematical libraries. when
i found that mathematical prelude discussion page at haskell.org, it was
disappointingly brief, so i might not have followed through to the sources,
which seem rather better developed. when i did go to the darcs site for
the sources, there were haddocks, but for introduction and overview,
there is only a brief entry for the haskell communities report, in .tex format.

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?

long ago, there was a start in Jeroen Fokker's
   
    Explaining Algebraic Theory with Functional Programs.
    FPLE 1995
    http://www.cs.uu.nl/people/jeroen/article/algebra/

but what would be today's updated equivalent?

claus

monad
-- one of the secret commands of haskellbot; when uttered on one of the
    channels haskellbot is lurking on (mailing lists, news groups, irc, blogs,
    feeds,..), it will generally result in yet another monad tutorial (YAMT)
    to be written and published; although, if haskellbot is bored, it might
    simply point randomly to one of its earlier works; documentation on
    haskellbot commands is sketchy, possibly to discourage trolls, but it
    has been known to react to "oop in haskell", "killer application",
    "mainstream", "static vs dynamic typing", and "category theory"


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

[David House]

On 25/03/07, Ian Lynagh <igloo@...> 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.

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

[Ian Lynagh]

[reply-to set; dropping libraries]

On Sun, Mar 25, 2007 at 04:33:51PM +0100, David House wrote:
> On 25/03/07, Ian Lynagh <igloo@...> 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

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

[Jacques Carette]

My main worry is that this can be a horrible time sink without a clear
path to success and, worse, known obstacles in the way.

For example: we know that all Monads are Functors, but that is not
expressed in the type classes, because it would be too much a pain to do
so.  That pain is heavily multiplied in a 'proper' subdivision of
mathematical types.  Until that is fixed, I know I do not consider it
worthwhile to spend a lot of time working on this because the end result
might be correct, but completely unrealistic.

Another obvious item is that the lessons from DoCon have not all been
reflected into advances in Haskell, not even Haskell'.  If I was in a
pessimistic mood, I would mention the lessons from AUTOMATH (you know,
stuff from 1968 to the mid 70s).

Claus Reinke wrote:
> ok, tongue out of cheek again, someone would need to investigate the
> particular shape in which such abstract concepts would be most useful
> (which may or may not be the same shape best known in maths, see
> Monad, Monoid, Applicative, Arrow,..), and how those shapes are best
> expressed within the programming language abilities. and then, of
> course, someone would need to write code and tutorials.
Agreed.  This is why I mentioned semi-groups when someone talked about
classical structures like rings and fields.  To pick just one example,
Kleene Algebras seem more applicable to CS than say fields.  Similarly,
there are more rngs and rigs than rings.  More applications for
non-archimedian fields (power series) than archimedean ones (reals).  
And so on.

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

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

[Sebastian Sylvan]

On 3/25/07, David House <dmhouse@...> wrote:

> On 25/03/07, Ian Lynagh <igloo@...> 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
[phone]
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[David House]

On 25/03/07, Ian Lynagh <igloo@...> wrote:
> You wouldn't have to import a number of different modules like
> Data.Function, you could just import Prelude.

I guess what I was getting at was that Haskell is very good at
blurring the distinction between userland function and actual syntax.
E.g. to the untrained eye 'otherwise' may seem like a keyword, but
it's defined in Data.Bool. Functions like map and catamorphisms like
maybe and foldr are used just like control structures, not to mention
things like when and unless which are built to directly emulate
control structures in other languages.

As real control structures, like if and case, are always in scope,
having _no_ functions imported by default would drive an unnatural
wedge between function and control structure.

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

[Stefan O'Rear]

On Sun, Mar 25, 2007 at 04:05:51PM +0100, 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.

My goal of sparking thought was sucessful :)

I like Claus Reinke's proposal, it solves all of my problems quite
nicely.

(Can we get that on the h' wiki?  It is rather similar (but definitely
different) to the minimal-prelude proposal on the Prelude page.)

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

[Jason Creighton]

On Sun, Mar 25, 2007 at 12:59:26AM -0400, ajb@... wrote:
> 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.

Data.Map is a Functor:

http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html#t%3AMap

~$ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base ... linking ... done.
Prelude> :m + Data.Map
Prelude Data.Map> fmap (*2) (fromList [(1,2), (3,4)])
fromList [(1,4),(3,8)]

...but perhaps it's not a Functor in some earlier version of the
library?

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

[Andrzej Jaworski]

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



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

[ajb-2]

G'day all.

Quoting Jason Creighton <jcreigh@...>:

> Data.Map is a Functor:
[...]
> ...but perhaps it's not a Functor in some earlier version of the
> library?

Possibly, if by "earlier version" you mean FiniteMap.

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

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

[Neil Mitchell]

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

[ajb-2]

G'day all.

Quoting Neil Mitchell <ndmitchell@...>:

> 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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

I can contribute a few.

On Mar 26, 2007, at 02:14 , ajb@... wrote:

> G'day all.
>
> Quoting Neil Mitchell <ndmitchell@...>:
>
>> 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@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Donald Bruce Stewart]

ajb:
> G'day all.
>
> Quoting Neil Mitchell <ndmitchell@...>:
>
> > 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, it'll break 100s of modules :-)

    $ find .  -name '*.hs' -exec grep -l 'import.*Data\.Map' {} \;  | wc -l
    545

You could also grep the 100+ packages on hackage.

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

[David Brown-22]

ajb@... wrote:
> G'day all.
>
> Quoting Neil Mitchell <ndmitchell@...>:
>
>> 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


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

[Neil Mitchell]

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

[David Brown-22]

David Brown wrote:

> ajb@... wrote:
>> G'day all.
>>
>> Quoting Neil Mitchell <ndmitchell@...>:
>>
>>> 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.

Ugh.  I need to pay attention more before replying.

I use Data.Map but never use Data.Map.map.  I usually transform the
data before putting it into the map.

Dave

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

[Lennart Augustsson]

I agree, I think this is what we need.
Plus a decision of what names the builtin syntax refers to,
like the type of 'a'.

        -- Lennart

On Mar 26, 2007, at 23:30 , Ashley Yakeley wrote:

> 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.
>> That should take of most issues.
>
> I think this is ideal. I've always thought writing "import Prelude"  
> was a good idea if one wants one's module to import the Prelude.  
> It's one less corner case.
>
> --
> Ashley Yakeley
>
> _______________________________________________
> Libraries mailing list
> Libraries@...
> http://www.haskell.org/mailman/listinfo/libraries

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

[Nicolas Frisby]

Gut feeling: the quick'n dirty script case occurs far less than the
whole module case. Thus I think the benefit of automatically importing
the Prelude if the module declaration is omitted should not happen:
the Principle of Least Surprise out-weighs the small benefit to a rare
case.

Correct me if I'm wrong about my hunch that the quick'n dirty case is
rare. Even so, I have a healthy respect both for Least Surprise and a
minimal number of behaviors when it comes to compilers.

My vote would be to never automatically import the Prelude, at least
not by default.

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.

On 3/27/07, Lennart Augustsson <lennart@...> wrote:

> I agree, I think this is what we need.
> Plus a decision of what names the builtin syntax refers to,
> like the type of 'a'.
>
>         -- Lennart
>
> On Mar 26, 2007, at 23:30 , Ashley Yakeley wrote:
>
> > 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.
> >> That should take of most issues.
> >
> > I think this is ideal. I've always thought writing "import Prelude"
> > was a good idea if one wants one's module to import the Prelude.
> > It's one less corner case.
> >
> > --
> > Ashley Yakeley
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries@...
> > http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> 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

[Arthur van Leeuwen]

On 27-mrt-2007, at 20:17, Nicolas Frisby wrote:

> Gut feeling: the quick'n dirty script case occurs far less than the
> whole module case. Thus I think the benefit of automatically importing
> the Prelude if the module declaration is omitted should not happen:
> the Principle of Least Surprise out-weighs the small benefit to a rare
> case.

In my experience quick'n'dirty scripts tend to end up as full-blown  
modules
later on in their life. This, to me, is a strong indication to make  
importing
the prelude explicit. Furthermore, the arguments against explicit  
importing
seem to be easier teaching and shorter code, as one needs much of the
Prelude almost everywhere. However, Java seems to offer a reasonable
datapoint in this argument: almost everything in the language needs
to be explicitly imported, but for java.lang. Ofcourse, java.lang is  
quite
annoyingly big... so a good example it is not.

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

Good point. It would also make the Prelude sources (and Haddock docs)
*much* easier to understand.

Doei, Arthur.

--

   /\    / |       arthurvl@...       | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody  
watching



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