Lambda the Ultimate

In the Spirit of C, by Greg Colvin.

A somewhat biased and over enthusiastic overview of the evolution of C and ilk.

I am sure LtU readers will find a lot they disagree with. I suggest starting with the quote from the ANSI C Rationale...

Software model checking is hard, but it is still a promising line of research.

Tools are generally influenced by the type of languages they model. On top of that, I am sure software model checking is going to influence language design and implementation.

True, this isn't about programming languages per se, but still an important work that some of you may want to check out.

I am not sure whether it is appropriate to ask for advice in this forum. If it isn't, please feel free to ignore/delete this message.

I have some questions regarding denotational semantics. I know operational semantics very well, but I did not yet understand some basic things about the denotational approach.

1. Every textbook says that "compositionality" is a very important property of d.s. I understand what this means. However, I have nowhere read *why* this is such an important property and what the consequences of being compositional are.

2. The examples of d.s. that are in most textbooks are so simple that they look trivially equivalent to a corresponding operational semantics. However, I read that d.s. is a more "abstract", "high-level" approach to describing the semantics. What would be an example where this property is evident in comparison to op. sem. ? Also, what are in general the advantages/disadvantages compared to op.sem.?

3. I have heard people say that writing an interpreter for a language in Haskell is roughly equivalent to writing a denotational semantics for it. Could somebody enlighten me why (or why not) this is the case?