| Steele and Sussman | March 10, 1976 | 29 | LAMBDA: The Ultimate Imperative |
Conclusions
We have expressed a number of programming constructs in terms of a simple applicative language, SCHEME, based on lambda calculus. It is not surprising that this is possible, since SCHEME is universal. What is surprising is that the transition is so natural. Most of the translations are syntactically local. The translated program is recognizably equivalent to the original, because the global structure is preserved. The translation process does not increase the size of the program very much.
Landin [Landin 65] and Reynolds [Reynolds 72] have used similar techniques to model programming constructs. However, their modelling languages contained much more machinery than what we have used in SCHEME. For example, Landin introduces a special J-operator to model GO TO, and L-values to model assignment. We show that GO TO and most assignments can be modelled using only the lambda-binding mechanism.
The transformations we provide for escape expressions and general L-values (i.e. l-values for all data structures , not just variables) are not as syntactically local as the others. the complexity of those transformations may indicate that escape expressions and L-values are not subsumed by the mechanism of lambda-binding (except in the trivial sense that lambda-binding is Turning-universal). If they turn out to be desirable constructs, they should be implemented as primitives.
It has been suggested that certain programming language constructs, in particular the GO TO, lend themselves to obscure coding practices. Some purposely omit such familiar constructs as GO TO in an attempt to constrain the programmer to refrain from particular styles of programming thought by the language designer to be "bad" in some sense. (Note Gotophobia) But any language with function calls, function values, conditionals, correct handling of tall-recursions, and lexical scoping can simulate such "non-structured" constructs as GO TO statements, call-by-name, and fluid variables in a straightforward manner. If the language also has a macro processor or preprocessor, these simulations will even be convienient to use. {Note Features}
No amount of language design can force a programmer to write clear programs. If the programmer's conception of the problem is badly organized, then his program will also be badly organized. The extent to which a programming language can help a programmer to organize his problem is precisely the extent to which it provides features appropriate to his problem domain. The emphasis should not be on eliminating "bad" language constructs but on discovering or inventing helpful ones.
