Mark Janssen writes: > > Having said that, theorists do want to unify concepts wherever possible > > and wherever they make sense. Imperative programming types, which I > > will call "storage types", are semantically the same as classes. > > I like that word "storage type", it makes it much clearer what one is > referring to.
Indeed. However, this is not the only notion of type in imperative programming languages. For example, a function type in C or its descendants is not there to describe storage, but to describe the interface of an abstraction. I will use Reynolds's term "phrase types" to refer to such types. Reynolds's main point in "The Essence of Algol" was to say that phrase types are much more general, and a language can be built around them in a streamlined way. Perhaps "Streamlining Algol" would have been a more descriptive title for his paper. Nobody should be designing an imperative programming language without having read "The Essence of Algol", but they do. Whether storage types (and their generalization, class types) should be there in a type system at all is an open question. I can think of arguments both ways. In Java, classes are types. So are interfaces (i.e., phrase types). I think Java does a pretty good job of combining the two in a harmonious way. If you have trouble getting hold of "The Essence of Algol", please write to me privately and I can send you a scanned copy. The Handout 5B in my "Principles of Programming Languages" lecture notes is a quick summary of the Reynolds's type system. http://www.cs.bham.ac.uk/~udr/popl/index.html > I feel like I'm having to "come up to speed" of the academic > community, but wonder how and why this large chasm happened between > the applied community and the theoretical. In my mind, despite the > ideals of academia, students graduate and they inevitably come to work > on Turing machines of some kind (Intel hardware, for example, > currently dominates). If this is not in some way part of some > "ideal", why did the business community adopt and deploy these most > successfully? Or is it, in some *a priori* way, not possible to apply > the abstract notions in academia into the real-world? The chasms are too many, not only between theoretical and applied communities, but within each of them. My feeling is that this is inevitable. Our field progresses too fast for people to sit back, take stock of what we have and reconcile the multiple points of view. There is nothing wrong with "Turing machines". But the question in programming language design is how to integrate the Turing machine concepts with all the other abstractions we need (functions/procedures, modules, abstract data types etc.), i.e., how to fit the Turing machine concepts into the "big picture". That is not an easy question to resolve, and there isn't a single way of doing it. So you see multiple approaches being used in the practical programming languages, some cleaner than the others. The abstract notions of academia do make it into the real world, but rather more slowly than one would hope. Taking Java for example, the initial versions of Java treated interfaces in a half-hearted way, ignored generics/polymorphism, and ignored higher-order functions. But all of them are slowly making their way into Java, with pressure not only from the academic community but also through competition from other "practical" languages like Python, C# and Scala. If this kind of progress continues, that is the best we can hope for in a fast-paced field like ours. Cheers, Uday Reddy -- Prof. Uday Reddy Tel: +44 121 414 2740 Professor of Computer Science Fax: +44 121 414 4281 School of Computer Science University of Birmingham Email: u.s.re...@cs.bham.ac.uk Edgbaston Birmingham B15 2TT Web: http://www.cs.bham.ac.uk/~udr -- http://mail.python.org/mailman/listinfo/python-list
