Difference between revisions of "The Other Prelude"

From HaskellWiki
Jump to navigation Jump to search
(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 () -- 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 and snd. 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