# The Other Prelude

### From HaskellWiki

Uchchwhash (Talk | contribs) (functor hierarchy proposal adoption) |
Uchchwhash (Talk | contribs) m (→See also) |
||

(34 intermediate revisions by 9 users not shown) | |||

Line 1: | Line 1: | ||

− | [[Category:Proposals]] |
+ | == Call For Contribution == |

− | == Call for contribution == |
+ | This fun project, called ''The Other Prelude'', is a creative reconstruction of the standard Prelude. By disregarding history and compatibility, we get a clean sheet. |

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

− | == Naming conventions == |
+ | == Committee == |

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

− | == Guidelines == |
+ | This project has no committee whatsoever. Issues are discussed on [[Talk:The Other Prelude|the talk page]]. |

− | * The prelude should not contain any "projection" functions (like <hask>fst</hask> and <hask>snd</hask>. They go to the Extension module. |
||

+ | == Naming Conventions == |
||

− | == Issues == |
+ | * Function names should be easy for beginners to consume. |

− | * Should alphanumeric names be preferred over symbols when defining a class? |
+ | * Specifically, ''The Other Prelude'' naming convention is to use |

+ | ** descriptive symbols for functions that are naturally infix (''e.g.'', <hask>mplus</hask> is replaced by <hask>(++)</hask>) |
||

+ | ** whole English words and camelCase for functions (''e.g.'', <hask>orElse</hask> but not <hask>fmap</hask>) |
||

+ | == Design Philosophy == |
||

− | == The hierarchy == |
+ | === Taking Typeclasses Seriously === |

+ | Following [[Not just Maybe]], functions should be generalized whenever possible. Of course, efficiency might be a concern but this is a fun project anyway. |
||

+ | * <hask>concat</hask> means the same thing as <hask>join</hask>. We propose we don't use <hask>concat</hask> at all. |
||

+ | * <hask>concatMap</hask> is just <hask>(>>=)</hask>. That is, monadic functions are preferred over the same functions with different name. |
||

+ | |||

+ | === The Hierarchy === |
||

+ | |||

+ | Although, not Haskell98, hierarchical modules are already in Haskell2010. We take it for granted. |
||

* <hask>TheOtherPrelude</hask> - Minimalistic module. |
* <hask>TheOtherPrelude</hask> - Minimalistic module. |
||

− | * <hask>TheOtherPrelude.Extension</hask> - Convenient definitions. |
+ | * <hask>TheOtherPrelude.Utilities</hask> - Convenient definitions. The reasoning behind its existence is that we want the Prelude to be very concise. It should not steal good names. |

+ | * <hask>TheOtherPrelude.Legacy</hask> - providing as much backwards compatibility as possible |
||

+ | |||

+ | == Open Issues == |
||

+ | |||

+ | * When the same function has an infix and a prefix implementation, should one of them be outside the class to enforce consistency? |
||

+ | * Should Prelude functions use <hask>Integer</hask> instead of <hask>Int</hask>? Maybe <hask>Integral n => n</hask> or <hask>Ix i => i</hask> in some cases? |
||

+ | * Should <hask>String</hask> be a class rather than a type synonym? |
||

+ | * The current proposal lacks a well thought <hask>fail</hask> mechanism. Should it be integrated into <hask>MonadZero</hask>, or have a class of his own, or remain in the <hask>Monad</hask> class? |
||

+ | |||

+ | == Reality == |
||

+ | |||

+ | What we have here right now is not ready to be adopted by existing projects. The [[class system extension proposal]] might make a difference. |
||

+ | |||

+ | == The Code == |
||

− | == 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. |
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, |
+ | The imaginary Prelude as it stands: |

+ | |||

+ | === <hask>TheOtherPrelude.hs</hask> === |
||

<haskell> |
<haskell> |
||

− | import Prelude () -- hide everything |
+ | {-# LANGUAGE NoImplicitPrelude #-} |

− | -- the idea is to remove 'fmap' |
+ | module TheOtherPrelude where |

− | -- and map :: (a -> b) -> [a] -> [b] to be a special case |
+ | |

+ | import Prelude (id, const, flip, (.)) |
||

+ | -- hide almost everything |
||

+ | -- in fact, we could do better, by just defining them here |
||

+ | |||

+ | -- The idea is to rename 'fmap'. |
||

+ | -- Both map :: (a -> b) -> [a] -> [b] (in []) |
||

+ | -- and (.) :: (a -> b) -> (e -> a) -> (e -> b) (in (->) e) |
||

+ | -- are good names, and are intuitively prefix and infix respectively. |
||

+ | -- 'map' is aliased as (.) below. |
||

class Functor f where |
class Functor f where |
||

map :: (a -> b) -> f a -> f b |
map :: (a -> b) -> f a -> f b |
||

+ | -- definitely a bad idea, sorry Cale! |
||

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

+ | -- (.) = map |
||

− | -- should the Functor hierarchy proposal be adopted? |
+ | class (Functor p) => Applicative p where |

− | -- |
+ | -- Minimal complete definition: return and (<@>). |

− | -- NO -- |
+ | pure :: a -> p a -- value lifting |

− | class Monad m where |
+ | -- actually I think we should |

− | (>>=) :: m a -> (a -> m b) -> m b |
+ | -- stick to return |

− | (>>) :: m a -> m b -> m b |
+ | -- to make do notation work |

− | return :: a -> m a |
+ | (<@>) :: p (a -> b) -> p a -> p b -- lifted application |

+ | (>>) :: p a -> p b -> p b -- when the second is independent of the first |
||

+ | |||

+ | pa >> pb = (const id) . pa <@> pb |
||

+ | --map f pa = return f <@> pa -- see Class system extension proposal, below |
||

+ | |||

+ | apply :: (Applicative p) => p (a -> b) -> p a -> p b |
||

+ | apply = (<@>) |
||

+ | |||

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

+ | -- Minimal complete definition: one of join or (>>=). |
||

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

+ | join :: m (m a) -> m a -- combining levels of structure |
||

+ | |||

+ | ma >>= k = join (map k ma) |
||

+ | join mma = mma >>= id |
||

+ | --mf <@> ma = mf >>= flip map ma -- see Class system extension proposal, below |
||

+ | --ma >> mb = ma >>= const mb |
||

+ | --map f ma = ma >>= return . f -- this depends on (.), which is map! Be careful. |
||

+ | |||

+ | -- We copy from the MonadPlus reform proposal (link below) now. |
||

+ | -- 'zero' will be used when pattern matching against refutable patterns in |
||

+ | -- do-notation as well as to provide support for monad comprehensions. |
||

+ | |||

+ | class (Monad mz) => MonadZero mz where |
||

+ | -- Should satisfy 'left zero': zero >>= f = zero |
||

+ | zero :: mz a |
||

+ | |||

+ | class (MonadZero mp) => MonadPlus mp where |
||

+ | -- Should satisfy 'monoid': |
||

+ | -- zero ++ b = b; b ++ zero = b |
||

+ | -- (a ++ b) ++ c = a ++ (b ++ c) |
||

+ | -- and 'left distribution': |
||

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

+ | (++) :: mp a -> mp a -> mp a |
||

+ | |||

+ | class (MonadZero mo) => MonadOr mo where |
||

+ | -- Should satisfy 'monoid': |
||

+ | -- zero `orElse` b = b; b `orElse` zero = b |
||

+ | -- (a `orElse` b) `orElse` c = a `orElse` (b `orElse` c) |
||

+ | -- and 'left catch': |
||

+ | -- (return a) `orElse` b = a |
||

+ | orElse :: mo a -> mo a -> mo a |
||

+ | |||

+ | class (Monad m) => MonadFail m where |
||

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

− | -- |
+ | </haskell> |

− | -- 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 |
+ | === <hask>TheOtherPrelude/Utilities.hs</hask> === |

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

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

− | -- this leaves little left for the actual Monad class |
+ | <haskell> |

− | class (Applicative f) => Monad f where |
+ | module TheOtherPrelude.Utilities where |

− | (>>=) :: f a -> (a -> f b) -> f b |
+ | import Prelude () -- hide everything |

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

− | -- end of Functor hierarchy dilemma |
+ | -- this is the if-then-else proposal |

+ | -- the name has been chosen to reflect the magic of Church booleans! |
||

+ | -- the order of arguments matches that of maybe and either. |
||

+ | boolean x _ True = x |
||

+ | boolean _ y False = y |
||

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

− | How to use it, as it stands, |
+ | == How To Use == |

<haskell> |
<haskell> |
||

− | import Prelude () -- hide everything |
+ | -- ''The Other Prelude'' is an alternative, not a replacement. |

− | import TheOtherPrelude -- get everything |
+ | -- So we need to hide everything from the Prelude |

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

+ | -- Now that we have it, |
||

+ | {-# LANGUAGE NoImplicitPrelude #-} |
||

+ | -- This is just an example assuming there is nothing to hide |
||

+ | import TheOtherPrelude |
||

+ | |||

+ | -- Hopefully, this module will contain lift,... |
||

+ | -- Standard convention is to use M.lift (instead of liftM) |
||

+ | -- import qualified TheOtherPrelude.Monad.Kleisli as M |
||

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

== See also == |
== 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 |
||

+ | * [[Class system extension proposal]] - Makes this proposal worth reading at last |
||

+ | * [[Quantified contexts]] - Another important issue |
||

+ | * [[Functor hierarchy proposal]] - Making <hask>Monad m</hask> imply <hask>Functor m</hask> (adopted by ''The Other Prelude''). |
||

+ | * [[Functor-Applicative-Monad Proposal]] - in essence the same proposal, perhaps showing this sentiment is more common than assumed |
||

+ | * [[If-then-else]] - Making <hask>if</hask> a function (partially adopted by ''The Other Prelude'', we are silent on the bigger issue of sugar). |
||

+ | * [http://software.complete.org/missingh/static/doc/ MissingH] - Functions "missing" from the Haskell Prelude/libraries. |
||

+ | * [[MonadPlus reform proposal]] - Clarifies ambiguities around MonadPlus laws (adopted by ''The Other Prelude'') |
||

+ | * [[Mathematical prelude discussion]] - A [[Numeric Prelude]] in good shape already. Will a merger be ever possible? |
||

+ | * [[Prelude extensions]] and [[List function suggestions]] - Unlike ''The Other Prelude'' they ''enhance'' the Prelude. |
||

+ | * [[Not just Maybe]] - Instead of writing inside a specific monad (i.e. Maybe) write functions generalized on (Monad m)=> where possible. |
||

+ | |||

+ | [[Category:Proposals]] |
||

[[Category:Mathematics]] |
[[Category:Mathematics]] |
||

[[Category:Code]] |
[[Category:Code]] |

## Latest revision as of 22:37, 22 December 2010

## Contents |

## [edit] 1 Call For Contribution

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

## [edit] 2 Committee

This project has no committee whatsoever. Issues are discussed on the talk page.

## [edit] 3 Naming Conventions

- Function names should be easy for beginners to consume.
- Specifically,
*The Other Prelude*naming convention is to use- descriptive symbols for functions that are naturally infix (
*e.g.*,is replaced bymplus)(++) - whole English words and camelCase for functions (
*e.g.*,but notorElse)fmap

- descriptive symbols for functions that are naturally infix (

## [edit] 4 Design Philosophy

### [edit] 4.1 Taking Typeclasses Seriously

Following Not just Maybe, functions should be generalized whenever possible. Of course, efficiency might be a concern but this is a fun project anyway.

- means the same thing asconcat. We propose we don't usejoinat all.concat
- is justconcatMap. That is, monadic functions are preferred over the same functions with different name.(>>=)

### [edit] 4.2 The Hierarchy

Although, not Haskell98, hierarchical modules are already in Haskell2010. We take it for granted.

- - Minimalistic module.TheOtherPrelude
- - Convenient definitions. The reasoning behind its existence is that we want the Prelude to be very concise. It should not steal good names.TheOtherPrelude.Utilities
- - providing as much backwards compatibility as possibleTheOtherPrelude.Legacy

## [edit] 5 Open Issues

- When the same function has an infix and a prefix implementation, should one of them be outside the class to enforce consistency?
- Should Prelude functions use instead ofInteger? MaybeIntorIntegral n => nin some cases?Ix i => i
- Should be a class rather than a type synonym?String
- The current proposal lacks a well thought mechanism. Should it be integrated intofail, or have a class of his own, or remain in theMonadZeroclass?Monad

## [edit] 6 Reality

What we have here right now is not ready to be adopted by existing projects. The class system extension proposal might make a difference.

## [edit] 7 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 imaginary Prelude as it stands:

### [edit] 7.1 TheOtherPrelude.hs

{-# LANGUAGE NoImplicitPrelude #-} module TheOtherPrelude where import Prelude (id, const, flip, (.)) -- hide almost everything -- in fact, we could do better, by just defining them here -- The idea is to rename 'fmap'. -- Both map :: (a -> b) -> [a] -> [b] (in []) -- and (.) :: (a -> b) -> (e -> a) -> (e -> b) (in (->) e) -- are good names, and are intuitively prefix and infix respectively. -- 'map' is aliased as (.) below. class Functor f where map :: (a -> b) -> f a -> f b -- definitely a bad idea, sorry Cale! -- (.) :: (Functor f) => (a -> b) -> f a -> f b -- (.) = map class (Functor p) => Applicative p where -- Minimal complete definition: return and (<@>). pure :: a -> p a -- value lifting -- actually I think we should -- stick to return -- to make do notation work (<@>) :: p (a -> b) -> p a -> p b -- lifted application (>>) :: p a -> p b -> p b -- when the second is independent of the first pa >> pb = (const id) . pa <@> pb --map f pa = return f <@> pa -- see Class system extension proposal, below apply :: (Applicative p) => p (a -> b) -> p a -> p b apply = (<@>) class (Applicative m) => Monad m where -- Minimal complete definition: one of join or (>>=). (>>=) :: m a -> (a -> m b) -> m b -- bind join :: m (m a) -> m a -- combining levels of structure ma >>= k = join (map k ma) join mma = mma >>= id --mf <@> ma = mf >>= flip map ma -- see Class system extension proposal, below --ma >> mb = ma >>= const mb --map f ma = ma >>= return . f -- this depends on (.), which is map! Be careful. -- We copy from the MonadPlus reform proposal (link below) now. -- 'zero' will be used when pattern matching against refutable patterns in -- do-notation as well as to provide support for monad comprehensions. class (Monad mz) => MonadZero mz where -- Should satisfy 'left zero': zero >>= f = zero zero :: mz a class (MonadZero mp) => MonadPlus mp where -- Should satisfy 'monoid': -- zero ++ b = b; b ++ zero = b -- (a ++ b) ++ c = a ++ (b ++ c) -- and 'left distribution': -- (a ++ b) >>= f = (a >>= f) ++ (b >>= f) (++) :: mp a -> mp a -> mp a class (MonadZero mo) => MonadOr mo where -- Should satisfy 'monoid': -- zero `orElse` b = b; b `orElse` zero = b -- (a `orElse` b) `orElse` c = a `orElse` (b `orElse` c) -- and 'left catch': -- (return a) `orElse` b = a orElse :: mo a -> mo a -> mo a class (Monad m) => MonadFail m where fail :: String -> m a

### [edit] 7.2 TheOtherPrelude/Utilities.hs

module TheOtherPrelude.Utilities where import Prelude () -- hide everything -- this is the if-then-else proposal -- the name has been chosen to reflect the magic of Church booleans! -- the order of arguments matches that of maybe and either. boolean x _ True = x boolean _ y False = y

## [edit] 8 How To Use

-- ''The Other Prelude'' is an alternative, not a replacement. -- So we need to hide everything from the Prelude --import Prelude () -- Now that we have it, {-# LANGUAGE NoImplicitPrelude #-} -- This is just an example assuming there is nothing to hide import TheOtherPrelude -- Hopefully, this module will contain lift,... -- Standard convention is to use M.lift (instead of liftM) -- import qualified TheOtherPrelude.Monad.Kleisli as M

## [edit] 9 See also

- Class system extension proposal - Makes this proposal worth reading at last
- Quantified contexts - Another important issue
- Functor hierarchy proposal - Making implyMonad m(adopted byFunctor m
*The Other Prelude*). - Functor-Applicative-Monad Proposal - in essence the same proposal, perhaps showing this sentiment is more common than assumed
- If-then-else - Making a function (partially adopted byif
*The Other Prelude*, we are silent on the bigger issue of sugar). - MissingH - Functions "missing" from the Haskell Prelude/libraries.
- MonadPlus reform proposal - Clarifies ambiguities around MonadPlus laws (adopted by
*The Other Prelude*) - Mathematical prelude discussion - A Numeric Prelude in good shape already. Will a merger be ever possible?
- Prelude extensions and List function suggestions - Unlike
*The Other Prelude*they*enhance*the Prelude. - Not just Maybe - Instead of writing inside a specific monad (i.e. Maybe) write functions generalized on (Monad m)=> where possible.