cs252r : Advanced Functional Programming - Fall 2006

These pages are a record of the in-class discussions for the graduate class "Advanced Functional Programming" given at Harvard University in the Fall of 2006.

October 25, 2006

Both C++ and Ada enable a programmer to overload functions, procedures, methods, and operators. Are there things you can do with type classes that you can not do in C++ or Ada?

In C++, the programmer can not overload on the return type of functions; implementing the Read class might be difficult.

How do you imagine the Haskell community reacted to type classes? How might implementers have reacted?

Users were probably very happy about this paper. Implementers were also probably pretty happy, but there may have been worries about the performance impact of adding the extra level of indirection to function calls.

What limitations do you see for the method?

Type classes can be implemented by passing dictionaries. Which of the rules in Appendix A arrange for dictionaries to be passed?

The REL rule.

Explain what you expect to happen if you should type check each of these terms in a Haskell interpreter: 

a = show True
b = show 9
c = read "True"
d = show (read "9")

Both (c) and (d) could be fixed by adding type annotations. 

c = read "True" :: Bool
d = show (read "9" :: Int)

remark: Some versions of ghci (namely, version 6.4.2 on my power mac), will allow (d) for numeric types, however, according to the Haskell 98 report, (d) should be a type error. The same version of ghci also reports a type of (Read a => a) for the expression (read "9"); this is probably due to some kind of interaction with the defaulting mechanism for the Num class?

XML Parsing

Suppose you have the following types and functions for parsing XML documents: 

type Parser a b = [a] -> [(b, [a])]

type Args  = [(String,String)]
type Label = String
data Xml   = String String
           | Elem Label Args [Xml]

elem :: Label -> Parser XML b -> Parser Xml b
elem lbl p = (Elem lbl' _ contents : xs)
           | lbl == lbl' = map (\(a,_) -> (a,xs)) (p contents)
elem _ _ _ = []

string :: Parser Xml String
string (String s : xs) = [(s,xs)]
string _               = []

We also have two combinators, anywhereX and everywhereX that find one or all of the occurances of a stanza. 

anywhereX   :: Parser Xml b -> Parser Xml b
anywhereX p xs = any xs (drop p xs)
  where
    any []                  tail = tail
    any (String _ : xs)     tail = any xs tail
    any (Elem _ _ xs' : xs) tail = any xs (drop p xs' ++ any xs' tail)

    drop p xs = map (\(a,xs) -> (a,[])) (p xs)

everywhereX :: Parser Xml b -> Parser Xml [b]
...

We may also have an anywhere and eveywhere for parsing strings: 

anywhereX   :: Parser String b -> Parser String b
everywhereX :: Parser String b -> Parser String [b]

Using only parametric polymorphism, is it possible to define a single anywhere of type (Parser a b -> Parser a b), tat can be used for both strings and XML documents?

No, we must know something about the structure of the type.

Define a class (Searchable a) with suitable methods, and write a generic version of anywhere that has type:

 anywhere :: Searchable a => Parser a b -> Parser a b 
instance Searchable Xml where
  subs (String _)     = []
  subs (Elem _ _ xs') = xs'

anywhereX   :: Parser Xml b -> Parser Xml b
anywhereX p xs = any xs (drop p xs)
  where
    any []      tail = tail
    any (x: xs) tail = case subs x of
                         []  -> any xs tail
                         xs' -> any xs (drop p xs' ++ any xs' tail)
    drop p xs = map (\(a,xs) -> (a,[])) (p xs)

BibTeX

@InProcesdings{P.-Wadler-and-S.-Blott1989
  , isbn       = "0-89791-294-2"
  , author     = "P. Wadler and S. Blott"
  , year       = 1989
  , publisher  = "ACM Press"
  , title      = "How to make ad-hoc polymorphism less ad hoc"
  , address    = "New York, NY, USA"
  , location   = "Austin, Texas, United States"
  , url        = "http://doi.acm.org/10.1145/75277.75283"
  , pages      = "60--76"
  , booktitle  = "Proceedings of the 16th ACM SIGPLAN-SIGACT symposium on Principles of programming languages"
  }