# The Other Prelude

### From HaskellWiki

(Difference between revisions)

BrettGiles (Talk | contribs) (Title conventions on hawiki pages) |
Uchchwhash (Talk | contribs) (functor hierarchy proposal adoption) |
||

Line 35: | Line 35: | ||

-- should the Functor hierarchy proposal be adopted? |
-- should the Functor hierarchy proposal be adopted? |
||

+ | -- |
||

+ | -- NO -- |
||

class Monad m where |
class Monad m where |
||

(>>=) :: m a -> (a -> m b) -> m b |
(>>=) :: m a -> (a -> m b) -> m b |
||

Line 40: | Line 42: | ||

return :: a -> m a |
return :: a -> m a |
||

fail :: String -> m a |
fail :: String -> m a |
||

+ | -- |
||

+ | -- YES -- |
||

+ | -- the following has been shamelessly copied |
||

+ | -- from the functor hierarchy proposal wiki page |
||

+ | class Functor f => Applicative f where |
||

+ | return :: a -> f a |
||

+ | (<*>) :: f (a -> b) -> f a -> f b -- or should this be named 'ap'? |
||

+ | -- or something even better? |
||

+ | -- could this nice looking function |
||

+ | -- refactor the liftM* idioms? |
||

+ | |||

+ | -- my undestanding is that this is the default for monad |
||

+ | (>>) :: Applicative f => f a -> f b -> f b |
||

+ | fa >> fb = (map (const id) fa) <*> fb |
||

+ | |||

+ | -- this leaves little left for the actual Monad class |
||

+ | class (Applicative f) => Monad f where |
||

+ | (>>=) :: f a -> (a -> f b) -> f b |
||

+ | fail :: String -> f a |
||

+ | |||

+ | -- end of Functor hierarchy dilemma |
||

</haskell> |
</haskell> |
||

Line 46: | Line 69: | ||

<haskell> |
<haskell> |
||

− | import Prelude () -- hide everything |
+ | import Prelude () -- hide everything |

− | import TheOtherPrelude -- get everything |
+ | import TheOtherPrelude -- get everything |

− | import qualified TheOtherPrelude.Monad as M -- standard convention |
+ | import qualified TheOtherPrelude.Monad.Kleisli as M -- standard convention |

</haskell> |
</haskell> |
||

## Revision as of 04:03, 22 December 2006

## Contents |

## 1 Call for contribution

This fun project, called "The Other Prelude", and is a creative reconstruction of the standard Prelude. By disregarding history and compatibility, we get a clean sheet.

## 2 Naming conventions

The principal is to make the names very readable for both beginners and category theorists (if any).

## 3 Guidelines

- The prelude should not contain any "projection" functions (like andfst. They go to the Extension module.snd

## 4 Issues

- Should alphanumeric names be preferred over symbols when defining a class?

## 5 The hierarchy

- - Minimalistic module.TheOtherPrelude
- - Convenient definitions.TheOtherPrelude.Extension

## 6 The code

Currently, the code is in Wiki form. If people do agree that the collaborative decisions begot something pretty, we'll have a group of files in darcs.haskell.org some time.

The imaginery Prelude as it stands,

import Prelude () -- hide everything -- the idea is to remove 'fmap' -- and map :: (a -> b) -> [a] -> [b] to be a special case class Functor f where map :: (a -> b) -> f a -> f b -- should the Functor hierarchy proposal be adopted? -- -- NO -- class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- -- YES -- -- the following has been shamelessly copied -- from the functor hierarchy proposal wiki page class Functor f => Applicative f where return :: a -> f a (<*>) :: f (a -> b) -> f a -> f b -- or should this be named 'ap'? -- or something even better? -- could this nice looking function -- refactor the liftM* idioms? -- my undestanding is that this is the default for monad (>>) :: Applicative f => f a -> f b -> f b fa >> fb = (map (const id) fa) <*> fb -- this leaves little left for the actual Monad class class (Applicative f) => Monad f where (>>=) :: f a -> (a -> f b) -> f b fail :: String -> f a -- end of Functor hierarchy dilemma

How to use it, as it stands,

import Prelude () -- hide everything import TheOtherPrelude -- get everything import qualified TheOtherPrelude.Monad.Kleisli as M -- standard convention

## 7 See also

- Mathematical prelude discussion - A numeric Prelude. Could this be merged into this one?
- Prelude extensions and Prelude function suggestions - Unlike "The Other Prelude" they
*enhance*the Prelude. - Functor hierarchy proposal - making "Monad m" imply "Functor m"
- If-then-else - making "if" a function