Changes to the Haskell 1.3 Prelude

• New Types
• Reorganize the Ord class
• Add toEnum and fromEnum to Enum
• Add strictness annotation to Complex
• Use Int in take, drop, !!, and splitAt
• Add replicate, lookup, curry and uncurry
• Move functions into libraries
• Add the `bounded class'
• Numeric Issues
• Simplify lex
• Add undefined
• Add classes Monad, MonadZero, and MonadPlus
• Minor Changes

data  Maybe a  =  Nothing | Just a	deriving (Eq, Ord, Read, Show)

data  Either a b  =  Left a | Right b	deriving (Eq, Ord, Read, Show)

data  Void  -- No constructor, not in any classes

    if x == y then ...
    else if x < y then ...
    else ...

x < y = x <= y && x /= y

   case compare x y of
    EQ -> ...
    LT -> ...
    GT -> ...

Proposed Changes:

• Add a new type:

  data Ordering = LT | EQ | GT  deriving (Eq,Ord,Ix,Enum,Read, Show)
  

• Delete comment in definition of class Ord which explains how to define min and max for both total and partial orders.
• Change definition of Ord to

  class Eq a => Ord a where
     compare :: a -> a -> Ordering
     (<), (<=), (>=), (>):: a -> a -> Bool
     max, min	       :: a -> a -> a
     -- circular default definition:
     -- either <= or compare must be explicitly provided
       x < y	  	= compare x y == LT
       x <= y          = compare x y /= GT
       x > y              = compare x y == GT
       x >= y		= compare x y /= LT
       compare x y 
         | x == y    = EQ
         | x <= y    = LT
         | otherwise = GT
       max x y = case compare x y of
                  LT -> x
                  _  -> y
       min x y = case compare x y of
                  LT -> y
                  _  -> x
  

• Get the next value in enumeration: (\ x -> head (tail [x..]))
• Get the previous value in enumeration: no reasonable way
• Get the n'th value in enumeration: [C0..] !! (n - 1) (where C0 is first in enumeration)
• Find where a value occurs in an enumeration: lookup (zip [C0..] [0..]) x

Proposed changes:

• Add two new methods to Enum:

     toEnum   :: Int -> a
     fromEnum :: a -> Int
  

  Informally, given an enumeration:

   data T = C0 | C1 | ... Cm
  

  we have:

   toEnum i | 0 <= i && i <= m = Ci
            | otherwise           = error "Prelude.toEnum: result out of range"
   fromEnum Ci = i
  

  For example, given the datatype:

  
   data Colour = Red | Orange | Yellow | Green | Blue | Indigo | Violet
  

  we would have:

   toEnum 0 = Red
   toEnum 1 = Orange
   ...
   toEnum 6 = Violet
   toEnum _ = error "Prelude.toEnum: result out of range"
  

  and

   fromEnum Red    = 0
   fromEnum Orange = 1
   ...
   fromEnum Violet = 6
  

• Remove ord and chr fromPrelude and replace uses of ord and chr by fromEnum and toEnum respectively.
• Add these definitions to Prelude:

   succ, pred  :: Enum a => a -> a
   succ = toEnum . (+1) . fromEnum
   pred = toEnum . (+(-1)) . fromEnum
  

• The types of toEnum and fromEnum could be changed to:

     toEnum   :: Integer -> a
     fromEnum :: a -> Integer
  

  This would allow correct operation across the full range of integers, floats and doubles - but it's not clear that that is useful or necessary. The fact that toNum and fromEnum will fail in some instances doesn't bother us.
• The instances of enumFrom[Then][To] ought to be written carefully to avoid overflow. In particular we must avoid either of:

       [True..] = True : error "succ{Prelude}: result out of range"
       [maxChar..] = maxChar : error "succ{Prelude}: result out of range"
  

  This problem is present in Haskell 1.2 for the types Int, Float and Double where it doesn't seem to be troubling anyone.
• This proposal does not affect the cumulative rounding problems found in float and double.

Whereas changing the strictness of lists or integers would break many programs, only the most contrived programs will be affected by this change.

Proposed changes:

• Change definitions of Complex and Ratio to (both are now in libraries):

   data (RealFloat a) => Complex a = !a :+ !a deriving (Eq, Binary, Read, Show)
   data (Integral a)  => Ratio a   = !a :% !a deriving (Eq, Binary)
  

• To pass conformance tests such as:

     head (take (toInteger maxInt * 2) [1..]) == 1
  

• When dealing with very large datasets (more than 2^29 elements)

Proposed changes:

• Change the types of take, drop and splitAt to:

   take, drop :: Int -> [b] -> [b]
   splitAt :: Int -> [b] -> ([b]. [b])
   !! :: [a] -> Int -> a
  

Proposed Changes:

• Add replicate and lookup to PreludeList:

     replicate :: Int -> a -> [a]
     replicate n x = take n . repeat x
  
     lookup :: Eq a => a -> [(a,b)] -> Maybe b
     lookup key [] = Nothing
     lookup key ((x,y):xys) 
       | key == x  = Just y
       | otherwise = lookup key xys
  

• Add curry and uncurry to Prelude:

    curry :: ((a, b) -> c) -> a -> b -> c
    curry f x y = f (x,y)
  
    uncurry :: (a -> b -> c) -> (a, b) -> c
    uncurry f p = f (fst p) (snd p)
  

• Adding functions in the Prelude rather than a library forces the automatic import of the name into every Haskell program. This may break existing code which already uses these names or prevent a programmer from using these names for their own functions. (This is why we chose the name replicate instead of copy.) It also expands the "vocabulary" of Haskell - adding an extra name which Haskell programmers can be expected to know.

  In previous discussion, the name assoc was preferred to lookup to avoid stealing a useful name from the user. The library proposal also defines LibFiniteMap.lookup and LibHashTable.lookup - we feel that stealing the one name for three purposes is reasonable.

• An alternative definition for uncurry is:

        uncurry f (x, y) = f x y
  

  Which is slightly stricter. Does this matter?

It is possible to have our cake and eat it by simply moving rarely used functions into standard libraries (the language size remains the same but the "core language" gets smaller).

The following changes are based on counting how many times certain functions are used in a large body of Haskell programs (i.e. the Glasgow Haskell repository).

Many functions have been moved: see the new prelude to find out what remains.

The Bounded class

class Bounded a where
  minBound, maxBound :: a

Providing everything numerical analysts could ask for requires a large amount of work, especially since the basic operations do not fit into the existing numeric classes (Num, Ord, ...). We are planning to create a library which will provide strict LIA conformance. However, a few simple additions to the numerics will make it possible to take advantage of some features of IEEE floating point operations.

Proposed Changes:

• Add methods isNaN, isInfinite, isDenormalized and isIEEE to RealFloat:

    isNaN, isInfinite, isDenormalized, isIEEE, isNegativeZero
          :: RealFloat a => a -> Bool
  

  In non-IEEE implementations, these all return False. In IEEE implementations, isIEEE returns True and all others return appropriate responses.
• Add line to definition of showFloat:

    showFloat x =
      if isNaN x then showString "<<NaN>>" 
      else if isInfinite x then 
         if x < 0 then  showString "<<-Infinity>>"
  		else showString "<<Infinity>>"
      else if isNegativeZero x then
               showString ("-0." ++ take (m-2) (repeat '0')
      else if x == 0 then then showString ("0." ++ take (m-1) (repeat '0'))
      else if e >= m-1 || e < 0 then showSci else showFix
      where 
      -- remainder of function is unchanged
   
  It is not necessary for a string that is to be converted to a
  floating point number using one of the standard prelude functions
  to include a `.' character.  In Haskell 1.2, the expression:
      read "2" :: Double
  
  causes a run-time error; with the new prelude, the result is just
  2.0 :: Double.
  
  

• These changes do not preclude a library for full IEEE or LIA compatibility. Such a library is under development.
• There is also a need for versions of showFloat which provide control over the format used and the number of digits displayed (like the E,F and G format controls in C's printf function). These will be provided in a library.

Proposed Changes:

• Remove support in lex for:
  • Both forms of comment (change to lex)
  • <- (change to lex)
  • "^<ctrl-char>" tokens (change to lexLitChar)
  • octal tokens (change to lexLitChar)
  • hex tokens (change to lexLitChar)
  • ASCII abbreviations for control characters (change to lexLitChar)
• Move isOctDigit and isHexDigit to the same module as functions like isAscii and isControl.

• This won't make lex or read any more efficient. The problems are:
  • lex is built using the same fully backtracking technology as read (it returns a list of alternative parses instead of a single token) but the resulting flexibility doesn't seem to be used anywhere. This imposes a significant overhead with little reward.
  • lex produces strings rather than tokens. This means that every token has to be identified twice: once in lex where the input list is split into strings representing tokens and once in read where these strings are matched against required input. The most effective way of fixing this is to introduce a new datatype representing each token.
  • Derived instances of readsPrec (which is called by read) usually have the following form (see Appendix E):

       readsPrec d r = 
          readCon K1 k1 "K1" r ++
          readCon K2 k2 "K2" r ++
    	  ...
          readCon Km km "Km" r
    

    In order to successfully parse a string starting with "Km", readsPrec will call the lex function m times. If lex were separated from read by preprocessing the input into a token stream, lex would only have to be called once.
  • When parsing a type with infix constructors, the derived instance of readsPrec may relex and reparse the same expression many times.
• Though a good start, this doesn't make lex much easier to understand. A more effective specification would be a grammar or regular expression. This would also simplify the task of feeding the specification into a Haskell lexer/parser generator or some similar (more appropriate) implementation technology.
• Haskell 1.3 will support hex (and octal) specification of numbers. It isn't clear whether lex should be modified to support this.

undefined = error "undefined{Prelude}"

Proposed Changes: Add these classes to Prelude:

  infixr 1  >>, >>=

  class Functor where
    map :: (a -> b) -> m a -> m b

  class Monad m where
    (>>=) :: m a -> (a -> m b) -> m b
    (>>)  :: m a -> m b -> m b
    return :: a -> m a

  class Monad m => MonadZero m where
    zero :: m a

  class MonadZero m => MonadPlus m where
    (++) :: m a -> m a -> m a

• Improve error messages for maximum and minimum:

    maximum [] =  error "maximum{PreludeList}: empty list" 
    maximum l  =  foldl1 max l
    minimum [] =  error "minimum{PreludeList}: empty list" 
    minimum l  =  foldl1 min l
  

  The error messages for head, tail, init and last use "[]" in their error messages; these will be changed to "empty list" for consistency.
• Add these equations to end of definitions of take, drop and splitAt.

    take _ _    = error "take{PreludeList}: negative argument"
    drop _ _    = error "drop{PreludeList}: negative argument"
    splitAt _ _ = error "splitAt{PreludeList}: negative argument"
  

• Add backquote to list of symbols in definition of isSingle in definition of lex.
• Remove even/odd from Integral because we can't imagine why they're not just normal overloaded functions.
• Change error messages to use qualified naming:

    maximum [] =  error "PreludeList.maximum: empty list" 
  

• The data type Assoc (used in array comprehensions) has been replaced by tuples. Occurances of x := y must be replaced by (x,y) .
• It will be made clear that duplicate indices in array comprehensions must be detected at runtime by a conforming Haskell implementation.
• All instances of index will generate a nice error message (mentioning the type involved) when the index is out of range.

Back to the Haskell Report.