Difference between revisions of "The Other Prelude"
From HaskellWiki
CaleGibbard (talk  contribs) 
m (use "Integer" instead of "Int") 

Line 13:  Line 13:  
== Issues == 
== Issues == 

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

+  * Why do many functions in Prelude use <hask>Int</hask> instead of <hask>Integer</hask>? IMO, <hask>Integer</hask> should be THE preferred datatype for everything (examples: length, splitAt, replicate, drop, take, ...)! 

Revision as of 02:09, 26 December 2006
Contents
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?
 Why do many functions in Prelude use
Int
instead ofInteger
? IMO,Integer
should be THE preferred datatype for everything (examples: length, splitAt, replicate, drop, take, ...)!
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
 as well as having (.) :: (a > b) > (e > a) > (e > b) as a
 special case from the Functor instance for ((>) e)
 Both notations can be provided to allow for clarity in different situations.
class Functor f where
map :: (a > b) > f a > f b
(.) :: (a > b) > f a > f b
map = (.)
(.) = map
 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?
(>>) :: f a > f b > f b
fa >> fb = (map (const id) fa) <*> fb
 this leaves little left for the actual Monad class
class (Applicative m) => Monad m where
(>>=) :: m a > (a > m b) > m b
join :: m (m a) > m a
x >>= f = join (map f x)
join x = x >>= id
 end of Functor hierarchy dilemma
 zero will be used when pattern matching against refutable patterns in
 donotation as well as to provide support for monad comprehensions.
class (Monad m) => MonadZero m where
zero :: m a
class (MonadZero m) => MonadPlus m where
(++) :: m a > m a > m a
class (MonadZero m) => MonadOr m where
orElse :: m a > m a > m a
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"
 Ifthenelse  making "if" a function
 MissingH  functions "missing" from the haskell Prelude/libraries