[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Uday S Reddy
u.s.reddy at cs.bham.ac.uk
Mon Apr 15 05:06:21 EDT 2013
Mark Janssen writes:
> After the 2001 "type/class unification" , it went towards Alan Kay's ideal
> of "everything is an object"....
> As a contrast, this is very distinct from C++, where everything is
> concretely rooted in the language's type model which in *itself* is
> rooted (from it's long history) in the CPU architecture. ...
> My question is: Is there something in the Computer Science literature
> that has noticed this distinction/development in programming language
> design and history?
In programming language theory, there is no law to the effect that
"everything" should be of one kind or another. So, we would not go with
Alan Kay's ideal.
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. Bare storage types
have predefined operations for 'getting' and 'setting' whereas classes allow
user-defined operations. So, the distinction made between them in typical
programming languages is artificial and implementation-focused. C and C++
are especially prone to this problem because they were designed for writing
compilers and operating systems where proximity to the machine architecture
seems quite necessary. The higher-level languages such as Java are moving
towards abolishing the distinction. Scala might be the best model in this
respect, though I do not know its type system fully.
Here are a couple of references in theoretical work that might be helpful in
understanding these connections:
- John Reynolds, The Essence of Algol, in de Bakker and van Vliet (eds)
Algorithmic Languages, 1981. Also published in O'Hearn and Tennent (eds)
Algol-like Languages, Vol. A, 1997.
- Uday Reddy, Objects and Classes in Algol-like Languages, Information and
Computation, 172:63-97, 2002. (previously in FOOL workshop 1998.)
However, there are properties that are special to storage types, which are
not shared by all class types. Sometimes, they simplify some theoretical
aspects. It is not uncommon for authors to make a distinction between
storage types and general types. An example is one of our own papers:
- Swarup, Reddy and Ireland: Assignments for applicative languages, FPCA
More information about the Types-list