The Other Prelude
From HaskellWiki
(Difference between revisions)
(Title conventions on hawiki pages) |
(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
