# 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 () | + | import Prelude () -- hide everything |

− | import TheOtherPrelude | + | 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