jkff wrote:
To all those people who are in any sense interested in PL theory I'd like to recommend the book "Design concepts in programming languages" [...]
I ordered the book because of your description, and I agree completely. Besides the core points you already mentioned, it's also interesting to note what the book does not do (on purpose, for clearer exposition) * concepts are defined mathematically, and for each, a "mini" language is given that contains the concept (and not much else). and, there's lots of exercises (relating to these languages). - the book is *not* a review of how the design concepts are realized in different "real" programming languages. (There's other books that do this.) * the book avoids discussions on concrete syntax and parsing theory. Of the > 1200 pages, about 26 are on syntax, and it's just S-expressions. Again, very reasonable choice. * what they call "Pragmatics" contains a nice 100 pages on code generation that could be used in a compiler construction course. The approach is transformational: source, intermediate, and target languages are actually different subsets of one common language. The advantage is that you can discuss many small-step transformations, and still need only one semantics definition (and for implementation exercises, you could use one and the same interpreter for each). nit-pickingly, though: * Section 17.6.1 (in the "Compilation" part) tries to explain why the intermediate language is not explicitly typed. Using phrases like "explicit type information is often larger than the code it describes", "specifying each compiler stage becomes more complicated" etc. Well, this sounds like the typical "practicioner's complaint" that type systems may be nice, but only get in the way if you're doing real work. * in the Appendix on notation, he defines composition of functions the "wrong way around" (i.e., the Haskell way, (f.g)(x) = f(g(x)). This is of course very awkward, especially considering that functions are relations, and an element of a relation is a directed edge, and there's a very obvious meaning of how edges are composed to give a path. Well, the book's "solution" is to avoid to define composition of relations! (p. 1155, they only define the n-fold composition of a relation with itself, and there the problem does not show.) PS: I was shocked to find recently that Bourbaki (!) also defines functional composition "wrongly" (at least in the English edition of Elements of Math./Theory of Sets, II.3.7) but at least they are consistent and define composition of relations ("graphs") accordingly. They are very honest about this, e.g. "Let G1, G2, G3 be graphs. Then (G3 * G2) * G1 = G3 * (G2 * G1)." (note the order of the variables) -- View this message in context: http://www.nabble.com/Recommending-%22Design-concepts-in-programming-languag... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.