| Mark Guzdial wrote: | Does anyone know of any empirical evidence for the value | of types? Or is it a myth that we invented to rationalize the typing | needed to improve the compiler's performance?
I think that, as with many others, the word 'type' (and related concepts 'type checking', 'type safe', 'strong typing', etc.) are somewhat abused.
I believe Smith and Ungar when the say in "Programming as an Experience: The inspiration of Self" (section 2.1) that types were invented in order to help the programmer generate correct code. Then this same information was used to communicate design intention to humans. (I attach these paragraphs at the bottom of this note)
So, the first thing to make clear is: Who are the types intended for? - If the reader will be a human, we need the most general and abstract kind of types (ie set of messages to be understood). - If the reader will be a compiler, the most detailed and precise information is needed. Ole Agesen calls them "Concrete Type", and it is basically the class of an object. It would be nice that this information could be deduced automatically, and that is (Concrete) Type Inference.
I and some other guys at MathMorphs have been caught by this fascinating area. As a result of that research, I am writing the final work (like a thesis) to get my graduation in Computer Science. (The code is available at http://typeinference.swiki.net). One of the main differences with Ole's work is that we consider not only the class but also the instance variables when defining the (concrete) type of an object.
Now, the fragment from "Programming as an Experience"
Type Declarations. In order to understand the design of the Self language it helps to examine the assumptions that underlie language design. In the beginning, there were FORTRAN, ALGOL and Lisp. In all three of these languages the programmer only has to say what is necessary to execute programs. Since Lisp was interpreted, no type infor mation was supplied at all. Since ALGOL and FORTRAN were compiled, it was nec essary for programmers to specify primitive type information, such as whether a vari able contained an integer or a float, in order for the compiler to generate the correct in structions. As compiled languages evolved, it was discovered that by adding more static declarations, the compiler could sometimes create more efficient code. For example, in PL/I procedures had to be explicitly declared to be recursive, so that the compiler could use a faster procedure prologue for the nonrecursive ones.
Programmers noticed that this static declarative information could be of great value in making a program more understandable. Until then, the main benefit of declarations had been to the compiler, but with Simula 1 and PASCAL a movement was born; using dec larations both to benefit human readers and compilers.
In our opinion, this trend has been a mixed blessing, especially where objectoriented languages are concerned. The problem is that the information a human needs to under stand a program, or to reason about its correctness, is not necessarily the same informa tion that a compiler needs to make a program run efficiently. But most languages with declarations confuse these two issues, either limiting the efficiency gained from decla rations, or, more frequently hindering code reuse to such an extent that algorithms get duplicated and type systems subverted.
Francisco (Pancho) Garau Ph: (5411) 4319-6213. Fax: (5411) 4319-6422 garau@ar.ibm.com (work) - - - fgarau@bigfoot.com (home)
squeak-dev@lists.squeakfoundation.org