Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
I can't see why is it off topic, could someone explain it to me? –  Andrew Oct 26 '11 at 1:42
2  
There are a couple issues; I've touched it up and am sending it over to Programmers, where discussions like this are a little more welcome. –  Will Oct 26 '11 at 14:08
    
Ruby doesn't obey this principle: Assume expr gets the current stack trace. –  Landei Nov 18 '11 at 9:16
add comment

migrated from stackoverflow.com Oct 26 '11 at 14:09

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 12 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
Claus Reinke: "On functional programming, language design, and persistence" on Haskell at community.haskell.org/~claus/publications/fpldp.html –  Kris Nov 18 '11 at 9:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.