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.

September 25, 2006

In "Why Functional Programming Matters", Hughes makes the claim that functional programming is useful because is gives the programmer more opportunities to write modular code. Hughes claims that these additional opportunities come from higher-order functions and laziness.

What is modularity? In what sense does Hughes use the term?

A large part of the discussion centered around what modular code is, in the students' opinion, and how this compared to the descriptions of modular code given in the paper. Toward the end of the class, Norman asked: "What is modularity?" There was no consensus on the exact meaning of modularity, but a few conclusions did result. The class agreed that modularity should allow reasoning about independent components in isolation, and that localized changes should be possible. There was less agreement that the ability to replace components, or components being general purpose are central to the concept of modularity.

According to Hughes, modularity means not only the ability to reason about individual components, but also the ability to compose components together. The discussion did not touch on this second aspect of modularity in any detail, although it was mentioned.

Norman explained that, within the functional programming community, modularity implies that there is a reasoning principle. More specifically, to talk of modularity implies that a program can be divided into units, there are one or more mechanisms for composing units, and there is a reasoning principle that enables one to consider one unit at a time. The reasoning principle may or may not require explicit interfaces for other units with which a unit is composed.

What part of Hughes' paper leave you feeling skeptical?

Overall, the class seemed to think that laziness was overemphasized in the paper. Many aspects of functional programming come into play in the examples, but credit is primarily given to laziness. Some students felt that polymorphism and abstract data types are more important, and note discussed enough in the paper.

The examples in the paper all work wonderfully. This left some students wondering "where the bodies are buried". Surely, laziness must have some disadvantages, but none are revealed in the examples or in the paper. There was a lot of discussion about whether or not the techniques in the paper would scale to large programs.

What do you like about lazy evaluation?

Most students seemed to like lazy evaluation. In particular, the ability to generate large solutions and select a small part without worrying about unnecessary computation. The ability to generate infinite values was also mentioned.

What do you dislike about lazy evaluation?

The students agreed that laziness does not seem to work with side-effects: lazy evaluation seems to only work with pure computations. The class wondered if lazy evaluation was really practical. Several students had been exposed to monads and knew some of the answers to these problems.

The primary complaint about laziness was it makes predicting the performance of a program difficult. Several times, the example of an airplane control system was brought up; none of the students wanted to fly on a plane running Haskell.

What do you like about higher-order functions?

Everyone was very happy about higher-order functions; so much so, that there was almost no discussion of their benefits.

What do you dislike about higher-order functions?

For the most part, the class believed that all of the problems with higher-order functions had to do with their implementation, and they were not very concerned about this.

There was an interesting discussion about how to create the right abstractions. One student posited that higher-order functions are just too powerful, and leave the programmer with no clear strategies for using them: "Too much glue, not enough wood". Everyone agreed that the contracts paper was a great example of good abstraction, but that neither paper really gave any guidance on how to find the right abstractions. Norman mentioned that the functional community had not produced a good source of design methodologies akin to the "gang of four".

The class did come up with a few general guidelines, namely:

BibTeX

@article{John-Hughes1989
  , number     = 2
  , author     = "John Hughes"
  , journal    = "Computer Journal"
  , title      = "Why Functional Programming Matters"
  , volume     = 32
  , url        = "http://portal.acm.org/citation.cfm?id=63411"
  , pages      = "98--107"
  , year       = 1989
  }
@article{Simon-Peyton-Jones-and-Jean-Marc-Eber-and-Julian-Seward2000
  , isbn       = "1-58113-202-6"
  , author     = "Simon Peyton Jones and Jean-Marc Eber and Julian Seward"
  , publisher  = "ACM Press"
  , title      = "Composing contracts: an adventure in financial engineering (functional pearl)"
  , address    = "New York, NY, USA"
  , year       = 2000
  , url        = "http://research.microsoft.com/~simonpj/Papers/financial-contracts/contracts-icfp.htm"
  , pages      = "280--292"
  , booktitle  = "Proceedings of the fifth ACM SIGPLAN international conference on Functional programming"
  }