cs252r Record

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 11, 2006

Imperative functional programming. Simon L. Peyton Jones and Philip Wadler.
Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell. Simon Peyton Jones.

Overall, the class thought the paper was very good, and enjoyed reading and discussing it.

Using the IO monad to simulate Dialogues causes both duplicated work and a space leak. How, then, could anyone possibly be interested in the IO monad?

The students answered this question by comparing monads to dialogues. The students created two lists, one list of things that are bad about dialogues, and one list of things that are good about monads.

Dialogues Bad Monads Good

can't compose
synchronization easy to break
underlying implementation exposed
all operations must be built into dialogue type
efficient
can compose
do notation looks imperative

Dialogues Bad	Monads Good
can't compose synchronization easy to break underlying implementation exposed all operations must be built into dialogue type	efficient can compose do notation looks imperative

What is the central claim of the paper?

Monads are a practical, general framework for implementation and use of side-effects in a lazy setting.

remark: Norman was surprised by the student's findings. Norman believed that the central claim was lazy functional languages should used monads for IO.

remark: Norman, asked the class to consider what kinds of arguments are the most convincing.

The class thought that the following points help to strengthen the paper:

demonstration of expressiveness by encoding to/from dialogues
rigorous definitions
existence of an implementation
does no require changes to existing type system, etc.
additions do not break any existing programs

remark: Norman mentioned that compositionality and extensionality are also a strong arguments in favor of monads. Compositionality because monadic computations can be easily composed, and extensionality because new IO primitives can be added without changing any types or existing code.

To what degree to you think this paper has lasting value?

First, the students tried to decide what constitutes lasting value. They settled on three different kinds of value: lasting historical value, lasting technical contribution, and lasting explanatory value.

The paper gives a good historical perspective as to the state of the art before monads were so widely accepted. The paper is also a good tutorial about monads and how they work. Some students felt that the implementation has lasting value as a guide for compilers writers and functional programmers that want to use monads. Overall, the class felt that this paper had some lasting value in all categories.

remark: Norman asked the student to choose which category they felt the paper was most valuable.

What is an interesting thing you can do with the IO monad that you can not do in C?

remark: The class was a little bit hesitant on this question, mainly because they could imagine ways of doing just about anything in C. The fact that GHC actually compiles Haskell to C is evidence that anything Haskell can do C can do. The point of the question was lost a little during this discussion. Norman suggested that the students move on to other questions.

Mutable variables are lumped in with the IO monad. Why? Why are arrays given a monad of their own?

One of the key differences between arrays and refs is that the underlying representation used for refs is all of memory, whereas arrays can be represented by a list or a small memory buffer. The use of a monad for arrays is to provide an efficient implementation of arrays over the representation.

The class thought that refs could be put into any monad for the purposes of sequencing, not just the IO monad. However, references need to be in the IO monad in order to get sequencing with respect to other IO operations. So, in order to use references with other kinds of IO, you are forced to put references into the IO monad.

What are the limitations of the techniques proposed in this paper?

It is unclear how to mix different monads together.

Sometimes we may need to get out of the IO monad, but it is difficult to know if doing so (with performIO) is safe.

The class discussed cases where the strict ordering the IO mond enforces are unnecessary. For example, two reads of different referece cells. The properties of the IO monad are too strong for our needs in these cases. However, there is no way to relax the constraints enforced by the IO monad.

The type system does not check that the algebraic laws required for the "Monad" to be a monad are obeyed. The type system does not help you here. So, in this respect the Haskell "Monad" is too weak.

BibTeX

@InProceedings{Simon-L.-Peyton-Jones-and-Philip-Wadler1993
  , isbn       = "0-89791-560-7"
  , author     = "Simon L. Peyton Jones and Philip Wadler"
  , year       = 1993
  , publisher  = "ACM Press"
  , title      = "Imperative functional programming"
  , address    = "New York, NY, USA"
  , location   = "Charleston, South Carolina, United States"
  , url        = "http://portal.acm.org/citation.cfm?id=158524"
  , pages      = "71--84"
  , booktitle  = "POPL '93: Proceedings of the 20th ACM SIGPLAN-SIGACT symposium on Principles of programming languages"
  }
@InProceedings{Simon-Peyton-Jones2000
  , title      = "Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell"
  , url        = "http://research.microsoft.com/Users/simonpj/papers/marktoberdorf.ps.gz"
  , author     = "Simon Peyton Jones"
  , year       = 2000
  , booktitle  = "2000 Marktoberdorf Summer School"
  }