What is the good explanation of Tennent's Correspondence Principle?

Question

I found myself struggling to see what is this principle about and why is it so important for language design.

Basically, it states, that for every expression expr in language should be exactly the same as this construct:

(function () { return expr; })()

Also, I have heard that Ruby obeys this principle, while Python doesn't. I don't understand why this is true, or if it is true at all.

Answer 1

I have never heard before of "Tennent's Correspondence Principle" and even less of it being important in language design. Googling the expressions seems all to lead to one Neal Gafter blog of 2006 that lays down what he thinks it is and how he thinks it should apply to closures as well. And most all others in forums seem to refer to Gafter's entry.

Here is however a mentioning of said "T.C.P." by Douglas Crockford (a name i know and trust): http://java.sys-con.com/node/793338/ . In part

There are some things that can't be enclosed that way, such as return statements and break statements, which the advocates of Tennent's Correspondence Principle (or TCP) claim is a symptom of a bad smell. Yow! Language design is already difficult enough without having to cope with olfactory hallucinations. So to better understand the problem, I bought a copy of Tennent's 1981 book, Principles of Programming Languages.

It turns out that the Correspondence Principle is descriptive, not prescriptive. He uses it to analyze the (by now forgotten) Pascal programming language, showing a correspondence between variable definitions and procedure parameters. Tennent does not identify the lack of correspondence of return statements as a problem.

So seems therefore the name "Tennent's Correspondence Principle" is mis-used, and whatever Neal talks about possibly should be called "Gafter's Imagined and Possibly Generalized T.C.P."... or some such. In any event not enough to hide behind an out-of-print book name-curtain

Answer 2

To answer the question why Tennent's CP is so important for language design, I'd like to quote Neal Gafter:

Tennent's principles are very powerful because violations of them tend to show up in the language as flaws, irregularities, unnecessary restrictions, unexpected interactions or complications, and so on.

Any violation of TCP is likely to hurt some programmer in the future when he expects closures to work like non-closure code but finds that, in violation of TCP, they don't.

Answer 3

I see this as part of a general rule that a well designed language does what a programmer would naturally expect. If I have a block of code that I want to refactor into a closure, and I wrap that block with the appropiate syntax without really thinking about the individual lines of code, then I expect that block to do the same thing in the closure as it did inline. If some statements use the keyword "this" (perhaps implicitly) and the language makes "this" used inside the closure refer to an anonymous class used to represent it rather than the class that defines the method that defines the closure, then the meaning of those statements has changed, my block of code no longer does what I think it does, and I have to track down a bug and figure out how to change my code to work in the closure. A language that prevents me from having such problems is helpful.

The problem could also be mitigated with an IDE with smart refactoring tools, that could extract closures, detect potential problems, and even automatically adjust the extracted code to solve the problems.

Answer 4

Claus Reinke: regarding Tennent's "Language Design based on Semantic Principles"
Gives interesting interpretation of the principles:
"Correspondence is the principle that lets us say that

let(this=obj, x=5) { .. }  

and

((function(x) { .. }).call(obj,5))  

should be equivalent, and that anything we can do in formal parameter lists, we should also be able to do in declarations, and vice versa." [see also, Reinke, below.]

R. D. Tennent: Language design methods based on semantic principles
"Two language design methods based on principles derived from the denotational approach to programming language semantics are described and illustrated by an application to the language Pascal. The principles are, firstly, the correspondence between parametric and declarative mechanisms, and secondly, a principle of abstraction for programming languages adapted from set theory. Several useful extensions and generalizations of Pascal emerge by applying these principles, including a solution to the array parameter problem, and a modularization facility."

Claus Reinke: "On functional programming, language design, and persistence" on Haskell