PFPL Commentary

I am building a web page devoted to the 2nd edition of Practical Foundations for Programming Languages, recently published by Cambridge University Press.  Besides an errata, the web site features a commentary on the text explaining major design decisions and suggesting alternatives.  I also plan to include additional exercises and to make sample solutions available to faculty teaching from the book.

The purpose of the commentary is to provide the “back story” for the development, which is often only hinted at, or is written between the lines, in PFPL itself.  To emphasize enduring principles over passing fads, I have refrained from discussing particular languages in the book.  But this makes it difficult for many readers to see the relevance.  One purpose of the commentary is to clarify these connections by explaining why I said what I said.

As a starting point, I explain why I ignore the familiar concept of a “paradigm” in my account of languages.  The idea seems to have been inspired by Kuhn’s (in)famous book The Structure of Scientific Revolutions, and was perhaps a useful device at one time.  But by now the idea of a paradigm is just too vague to be useful, and there are many better ways to explain and systematize language structure.  And so I have avoided it.

I plan for the commentary to be a living document that I will revise and expand as the need arises.  I hope for it to provide some useful background for readers in general, and teachers in particular.  I wish for the standard undergraduate PL course to evolve from a superficial taxonomy of the weird animals in the language zoo to a systematic study of the general theory of computation.  Perhaps PFPL can contribute to effecting that change.




One Response to PFPL Commentary

  1. Matt Oliveri says:

    Hello. From commentary.pdf:
    “It is worth nothing that the industry standard is, regrettably, to use the name void for the type unit in the imperative setting.”

    This is false. The industry standard (C-derived languages, I assume) is that void is not a normal type at all. It indicates the absence of a return type for a “function” that doesn’t return a value. (But it does return control.) void is not allowed–for various technical reasons, depending on the language–in most contexts that require a type expression.

    For example, in Java, void is literally not a type expression, and trying to use it where a type expression is expected causes parsing errors.

    According to stack overflow, in recent C standards, void is a type, but it’s “incomplete”, and so it cannot be used as the declared type of a variable. (So this is a rather unusual notion of “type”.)

    In any case, it’s not the unit type.

    Hopefully this doesn’t seem too nitpicky. I just figured if you’re going to discuss terminological confusion over “void“, you should give the correct meanings.

    (Personally, I would avoid calling any type “void”. How ’bout “empty”?)

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: