Re[Haskell-cafe] commending "Design concepts in programming languages"

[j.waldmann]

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-languages%22-tp23301907p23422300.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.