Being lazy with class
A history of Haskell
Paul Hudak, Yale University
John Hughes, Chalmers University,
Simon Peyton Jones, Microsoft Research
Phil Wadler, University of Edinburgh
The late 1979s, early 1980s
Pure functional programming: Lazy functional
recursion, pattern matching, programming
comprehensions etc etc (Friedman, Wise,
(ML, SASL, KRC, Hope, Id) Henderson, Morris, Turner)
Lisp machines Lambda the Ultimate
SK combinators,
(Symbolics, LMI) (Steele, Sussman)
graph reduction
(Turner)
Dataflow architectures
(Dennis, Arvind et al)
e.g. (\x. x+x) 5
= S (S (K +) I) I 5
The late 1979s, early 1980s
Pure functional programming: Lazy functional
recursion, pattern matching, programming
comprehensions etc etc (Friedman, Wise,
(ML, SASL, KRC, Hope, Id) Henderson, Morris, Turner)
Lisp machines Lambda the Ultimate
SK combinators,
(Symbolics, LMI) (Steele, Sussman)
graph reduction
(Turner)
Dataflow architectures
(Dennis, Arvind et al)
Backus 1978
Can programming be
liberated from the von
Neumann style?
John Backus Dec 1924 – Mar 2007
The 1980s
Functional programming: Lazy functional
recursion, pattern matching,
FP is respectable
comprehensions etc etc
(ML, SASL, KRC, Hope, Id)
programming
(Friedman, Wise,
Henderson, Morris, Turner)
(as well as cool)
SK combinators,
Dataflow architectures graph reduction
Go forth and design
(Arvind et al) (Turner)
new languages
Backus
and new computers
Can programming be
liberated from the von
and rule the world
Neumann style?
Result
Chaos
Many, many bright young things
Many conferences
(birth of FPCA, LFP)
Many languages
(Miranda, LML, Orwell, Ponder, Alfl, Clean)
Many compilers
Many architectures
(mostly doomed)
Crystalisation
FPCA, Sept 1987: initial meeting.
A dozen lazy functional programmers, wanting to agree
on a common language.
Suitable for teaching, research, and application
Formally-described syntax and semantics
Freely available
Embody the apparent consensus of ideas
Reduce unnecessary diversity
Absolutely no clue how much work we were taking on
Led to...a succession of face-to-face meetings
April 1990 (2½ yrs later): Haskell 1.0 report
Haskell Curry
1900-1982
Timeline
Sept 87: kick off; choose name
Apr 90: Haskell 1.0
Aug 91: Haskell 1.1 (153pp)
May 92: Haskell 1.2 (SIGPLAN Notices) (164pp)
May 96: Haskell 1.3. Monadic I/O,
separate library report
Apr 97: Haskell 1.4 (213pp)
Feb 99: Haskell 98 (240pp)
Dec 02: Haskell 98 revised (260pp)
2003-2007 Growth spurt
WG2.8 June 1992
WG2.8 June 1992
Phil John
Paul
WG2.8 June 1992
Dorothy
Sarah
Haskell the cat (b. 2002)
Timeline
Sept 87: kick off
Apr 90: Haskell 1.0
Aug 91: Haskell 1.1 (153pp)
May 92: Haskell 1.2 (SIGPLAN Notices) (164pp)
(thank you Richard Wexelblat)
May 96: Haskell 1.3. Monadic I/O,
separate library report
Apr 97: Haskell 1.4 (213pp)
Feb 99: Haskell 98 (240pp)
Dec 02: Haskell 98 revised (260pp)
2003-2007 Growth spurt
Haskell 98
Haskell 98
• Stable
• Documented
• Consistent across
implementations
• Useful for teaching,
books
Haskell
Haskell + extensions
development • Dynamic, exciting
• Unstable,
undocumented,
implementations vary...
Timeline
Sept 87: kick off
Apr 90: Haskell 1.0
Aug 91: Haskell 1.1 (153pp)
May 92: Haskell 1.2 (SIGPLAN Notices) (164pp)
May 96: Haskell 1.3. Monadic I/O,
separate library report
Apr 97: Haskell 1.4 (213pp)
Feb 99: Haskell 98 (240pp)
The Book!
(thank you CUP)
Dec 02: Haskell 98 revised (260pp)
2003-2007 Growth spurt
History of most research
languages
Practitioners
1,000,000
10,000
100
The quick death
Geeks
1yr 5yr 10yr 15yr
Practitioners
Successful research languages
1,000,000
10,000
100
The slow death
Geeks
1yr 5yr 10yr 15yr
C++, Java, Perl, Ruby
Threshold of immortality
Practitioners
1,000,000
10,000
The complete
100 absence of death
Geeks
1yr 5yr 10yr 15yr
Haskell “Learning Haskell is a great way of
“I'm already looking at training yourself to think functionally
coding problems and my so you are ready to take full
mental perspective is now advantage of C# 3.0 when it comes
Practitioners
shifting back and forth out” (blog Apr 2007)
1,000,000 between purely OO and
more FP styled solutions”
(blog Mar 2007)
10,000
100
The second life?
Geeks
1yr 5yr 10yr 15yr
2003-7: growth spurt
Haskell Cafe (2000)
Haskell Communities
Report (2001)
IRC #Haskell (2001)
Haskell Weekly News
(2005)
Google Summer of
Code (2006)
GHC bug count climbs
When Haskell is dust,
what will it be
remembered for?
1. Purity and laziness
2. Type classes
3. Process and community
Purity
and
laziness
Laziness
Laziness was Haskell’s initial rallying cry
John Hughes’s famous paper “Why
functional programming matters”
– Modular programming needs powerful glue
– Lazy evaluation enables new forms of
modularity; in particular, separating generation
from selection.
– Non-strict semantics means that unrestricted
beta substitution is OK.
But...
Laziness makes it much, much harder to reason
about performance, especially space. Tricky uses
of seq for effect seq :: a -> b -> b
Laziness has a real implementation cost
Laziness can be added to a strict language
(although not as easily as you might think)
And it’s not so bad only having bV instead of b
So why wear the hair shirt of laziness?
Laziness keeps you pure
Every call-by-value language has given into
the siren call of side effects
But in Haskell
(print “yes”) + (print “no”)
just does not make sense. Even worse is
[print “yes”, print “no”]
So effects (I/O, references, exceptions)
are just not an option.
Result: prolonged embarrassment.
Stream-based I/O, continuation I/O...
but NO DEALS WIH THE DEVIL
Salvation through monads
A value of type (IO t) is an “action”
that, when performed, may do
some input/output before
delivering a result of type t.
eg.
getChar :: IO Char
putChar :: Char -> IO ()
Connecting I/O operations
(>>=) :: IO a -> (a -> IO b) -> IO b
return :: a -> IO a
eg.
getChar >>= (\a ->
getChar >>= (\b ->
putChar b >>= (\() ->
return (a,b))))
The do-notation
do {
getChar >>= \a -> a <- getChar;
==
getChar >>= \b -> b <- getChar;
putchar b >>= \()-> putchar b;
return (a,b) return (a,b)
}
Syntactic sugar only
Easy translation into (>>=), return
Deliberately imperative “look and feel”
Control structures
Values of type (IO t) are first class
So we can define our own “control structures”
forever :: IO () -> IO ()
forever a = do { a; forever a }
repeatN :: Int -> IO () -> IO ()
repeatN 0 a = return ()
repeatN n a = do { a; repeatN (n-1) a }
e.g. repeatN 10 (putChar „x‟)
What have we achieved?
The ability to mix imperative and purely-
functional programming, without ruining
either
All laws of pure functional programming
remain unconditionally true, even of actions
e.g.
let x=e in ...x....x...
=
....e....e.....
Fine grain control
reverse :: String -> String
o pure: no side effects
launchMissiles :: String -> IO [String]
o impure: international side effects
transfer :: Acc -> Acc -> Int -> STM ()
o transactional: limited effects (reading and
writing transactional variables
There are lots of useful monads,
not only I/O
The central challenge
Useful Arbitrary effects
No effects
Useless
Dangerous Safe
The challenge of effects
Plan A
(everyone else)
Useful Arbitrary effects Nirvana
“A good language should change the
way people think about software” Plan B
(Stroustrup, HOPL 2007) (Haskell)
No effects
Useless
Dangerous Safe
Two basic approaches: Plan A
Default = Any effect
Arbitrary effects Plan = Add restrictions
• Types play a major role
• Types blur into analyses
Examples
Regions
Ownership types
Vault, Spec#,
Cyclone, etc etc
Two basic approaches: Plan B
Default = No effects
Plan = Selectively permit effects
Again, types play
Two main approaches: a major role
Domain specific languages
(SQL, XQuery, MDX,
Google map/reduce)
Wide-spectrum functional Value oriented
languages + controlled programming
effects (e.g. Haskell)
Lots of cross-over
Plan A
(everyone else)
Useful Arbitrary effects Nirvana
Envy
Plan B
(Haskell)
No effects
Useless
Dangerous Safe
Lots of cross-over
Plan A
(everyone else)
Useful Arbitrary effects Nirvana
Ideas; e.g. Software
Transactional Memory Plan B
(retry, orElse) (Haskell)
No effects
Useless
Dangerous Safe
SLPJ conclusions
One of Haskell’s most significant
contributions is to take purity seriously,
and relentlessly pursue Plan B
The next ML will be pure, with effects
only via monads. The next Haskell will be
strict, but still pure.
Imperative languages will embody growing
(and checkable) pure subsets
Type classes
Type classes
Initially, just a neat
class Eq a where way to get systematic
(==) :: a -> a -> Bool
overloading of (==),
instance Eq Int where read, show.
i1 == i2 = eqInt i1 i2
instance (Eq a) => Eq [a] where
[] == [] = True
(x:xs) == (y:ys) = (x == y) && (xs == ys)
member :: Eq a => a -> [a] -> Bool
member x [] = False
member x (y:ys) | x==y = True
| otherwise = member x ys
Implementing type classes
data Eq a = MkEq (a->a->Bool)
eq (MkEq e) = e Class witnessed
by a “dictionary”
Instance of methods
dEqInt :: Eq Int declarations create
dictionaries
dEqInt = MkEq eqInt
dEqList :: Eq a -> Eq [a]
dEqList (MkEq e) = MkEq el
where el [] [] = True
el (x:xs) (y:ys) = x `e` y && xs `el` ys
Overloaded
functions
take extra
member :: Eq a -> a -> [a] -> Bool dictionary
member d x [] = False parameter(s)
member d x (y:ys) | eq d x y = True
| otherwise = member d x ys
Type classes over time
Type classes are the most unusual
feature of Haskell’s type system
Hey, what’s
Wild enthusiasm the big
deal?
Despair Hack,
Incomprehension hack,
hack
1987 1989 1993 1997
Implementation begins
Type classes have proved
extraordinarily convenient in practice
Equality, ordering, serialisation
Numerical operations. Even numeric In Haskell,
my 17 can
constants are overloaded definitely
be your 23
Monadic operations
class Monad m where
return :: a -> m a
(>>=) :: m a -> (a -> m b) -> m b
And on and on....time-varying
Note the
values, pretty-printing, collections, higher-kinded
reflection, generic programming, type variable, m
marshalling, monad transformers....
Quickcheck
propRev :: [Int] -> Bool
propRev xs = reverse (reverse xs) == xs
propRevApp :: [Int] -> [Int] -> Bool
propRevApp xs ys = reverse (xs++ys) ==
reverse ys ++ reverse xs
ghci> quickCheck propRev
OK: passed 100 tests
ghci> quickCheck propRevApp
OK: passed 100 tests
Quickcheck (which is just a Haskell 98 library)
Works out how many arguments
Generates suitable test data
Runs tests
Quickcheck
quickCheck :: Test a => a -> IO ()
class Test a where
test :: a -> Rand -> Bool
class Arby a where
arby :: Rand -> a
instance (Arby a, Test b) => Test (a->b) where
test f r = test (f (arby r1)) r2
where (r1,r2) = split r
instance Test Bool where
test b r = b
Type-class fertility
Higher kinded
Implicit
type variables
parameters (2000)
(1995)
Wadler/ Extensible
Multi- records (1996) Computation
Blott
parameter at the type
type
type classes level
classes
(1989) (1991) Functional
dependencies
(2000) Generic
Overlapping programming
instances
“newtype
deriving” Associated Testing
types (2005)
Derivable
type classes
Applications
Variations
Type classes summary
A much more far-reaching idea than we
first realised: the automatic, type-driven
generation of executable “evidence”
Many interesting generalisations, still
being explored
Variants adopted in Isabel, Clean,
Mercury, Hal, Escher
Danger of Heat Death
Long term impact yet to become clear
Process
and
community
A committee language
No Supreme Leader
A powerfully motivated design group who
trusted each other
The Editor and the Syntax Tzar
Committee explicitly disbanded 1999
Language complexity
“Languages are too complex,
fraught with dispensable features
and facilities.” (Wirth, HOPL 2007)
Much superficial complexity (e.g.
redundant syntactic forms),
No formal semantics
Nevertheless, underpinned by
Deeply Held Principles
“Deeply held principles”
System F is GHC’s intermediate language
(Well, something very like System F.)
data Expr
= Var Var
| Lit Literal
| App Expr Expr
| Lam Var Expr
| Let Bind Expr
| Case Expr Var Type [(AltCon, [Var], Expr)]
| Cast Expr Coercion
| Note Note Expr
| Type Type
type Coercion = Type
data Bind = NonRec Var Expr | Rec [(Var,Expr)]
data AltCon = DEFAULT | LitAlt Lit | DataAlt DataCon
Sanity check on wilder excesses
The Haskell
Gorilla
System FC
Rest of GHC
Haskell users
A smallish,
tolerant,
rather pointy-headed, and
extremely friendly
user-base makes Haskell nimble.
Haskell has evolved rapidly and
continues to do so.
Haskell users react to new features
like hyenas react to red meat
Lesson: avoid success at all costs
The price of usefulness
Libraries increasingly important:
– 1996: Separate libraries Report
– 2001: Hierarchical library naming structure, increasingly
populated
– 2006: Cabal and Hackage: packaging and distribution
infrastructure
Foreign-function interface increasingly important
– 1993 onwards: a variety of experiments
– 2001: successful effort to standardise a FFI across
implementations
Lightweight concurrency, asynchronous
exceptions, bound threads, transactional memory,
data parallelism...
Any language large enough to be
useful becomes dauntingly complex
Conclusion
Haskell does not meet Bjarne’s
criterion (be good enough on all axes)
Instead, like Self, it aspires to take
a few beautiful ideas (esp: purity and
polymorphism), pursue them single-
mindedly, and see how far they can
take us.
In the end, we want to infect your
brain, not your hard drive
Luck
Technical excellence helps, but is neither
necessary nor sufficient for a language
to succeed
Luck, on the other hand, is definitely
necessary
We were certainly lucky: the conditions
that led to Haskell are hard to
reproduce (witness Haskell’)
Fun
Haskell is rich enough to be useful
But above all, Haskell is a language in which
people play
– Programming as an art form
– Embedded domain-specific languages
– Type system hacks
Play leads to new discoveries
Encapsulating it all
data ST s a -- Abstract
newRef :: a -> ST s (STRef s a)
read :: STRef s a -> ST s a
write :: STRef s a -> a -> ST s ()
runST :: (forall s. ST s a) -> a
Stateful
computation Pure result
sort :: Ord a => [a] -> [a]
sort xs = runST (do { ..in-place sort.. })
Encapsulating it all
runST :: (forall s. ST s a) -> a
Higher rank type
Security of Monads
encapsulation
depends on
parametricity And that depends on type classes
to make non-parametric
operations explicit
(e.g. f :: Ord a => a -> a)
Parametricity depends on there
being few polymorphic functions
(e.g.. f:: a->a means f is the And it also depends
identity function or bottom) on purity (no side
effects)
The Haskell committee
Arvind Thomas Johnsson
Lennart Augustsson Mark Jones
Dave Barton Dick Kieburtz
Brian Boutel John Launchbury
Warren Burton Erik Meijer
Jon Fairbairn Rishiyur Nikhil
Joseph Fasel John Peterson
Andy Gordon Simon Peyton Jones [editor]
Maria Guzman Mike Reeve
Kevin Hammond Alastair Reid
Ralf Hinze Colin Runciman
Paul Hudak [editor] Philip Wadler [editor]
John Hughes [editor] David Wise
Jonathan Young
