Difference between revisions of "The Other Prelude"
Jump to navigation
Jump to search
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
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.
Naming conventions
The principal is to make the names very readable for both beginners and category theorists (if any).
Guidelines
- The prelude should not contain any "projection" functions (like
fst
andsnd
. They go to the Extension module.
Issues
- Should alphanumeric names be preferred over symbols when defining a class?
The hierarchy
TheOtherPrelude
- Minimalistic module.TheOtherPrelude.Extension
- Convenient definitions.
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
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