[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

[DeLesley Hutchins]

I'm not quite sure I understand your question, but I'll give it a shot.  :-)

The C/C++ model, in which the types are anchored to the machine hardware,
in the exception, not the rule.  In the academic literature,  "type theory"
is almost entirely focused on studying abstract models of computation that
are purely mathematical, and bear no resemblance to the underlying
hardware.  The lambda calculus is the most general, and most commonly used
formalism, but there are many others; e.g. Featherweight Java provides a
formal model of objects and classes as they are used in Java.

"Types and Programming Languages", by Benjamin Pierce, is an excellent
introductory textbook which describes how various language features,
including objects, can be formalized.  If you are interested in OOP, Abadi
and Cardelli's "Theory of Objects" is the obvious place to start, although
I'd recommend reading Pierce's book first if you want to understand it.
 :-)  Abadi and Cardelli discuss both class-based languages, and pure
object languages.  If you are interested in the type/object distinction in
particular, then I'll shamelessly plug my own thesis: "Pure Subtype
Systems" (available online), which describes a formal model in which types
are objects, and objects are types.  If you are familiar with the Self
language, then you can think of it as a type system for Self.

Once you have a type system in place, it's usually fairly straightforward
to compile a language down to actual hardware.  An interpreter, like that
used in Python, is generally needed only for untyped or "dynamic"
languages.  There are various practical considerations -- memory layout,
boxed or unboxed data types, garbage collection, etc. -- but the basic
techniques are described in any compiler textbook.  Research in the areas
of "typed assembly languages" and "proof carrying code" are concerned with
ensuring that the translation from high-level language to assembly language
is sound, and well-typed at all stages.

  -DeLesley



On Sun, Apr 14, 2013 at 8:48 PM, Mark Janssen <dreamingforward at gmail.com>wrote:

> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list]
>
> Hello,
>
> I'm new to the list and hoping this might be the right place to
> introduce something that has provoked a bit of an argument in my
> programming community.
>
> I'm from the Python programming community.  Python is an "interpreted"
> language.  Since 2001, Python's has migrated towards a "pure" Object
> model (ref: http://www.python.org/download/releases/2.2/descrintro/).
> Prior to then, it had both types and classes and these types were
> anchored to the underlying C code and the machine/hardware
> architecture itself.  After the 2001 "type/class unification" , it
> went towards Alan Kay's ideal of "everything is an object".  From
> then, every user-defined class inherited from the abstract Object,
> rooted in nothing but a pure abstract ideal.  The parser, lexer, and
> such spin these abstrations into something that can be run on the
> actual hardware.
>
> 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.   The STL,
> for example, has many Container types, but each of them requires using
> a single concrete type for homogenous containers or uses machine
> pointers to hold arbitrary items in heterogeneous containers (caveat:
> I haven't programmed in C++ for a long time, so it's possible this
> might not be correct anymore).
>
> My question is:  Is there something in the Computer Science literature
> that has noticed this distinction/development in programming language
> design and history?
>
> It's very significant to me, because as languages went higher and
> higher to this pure OOP model, the programmer+data ecosystem tended
> towards very personal object hierarchies because now the hardware no
> longer formed a common basis of interaction (note also, OOPs promise
> of re-usable code never materialized).
>
> It's not unlike LISP, where the power of its general language
> architecture tended towards hyperpersonal mini macro languages --
> making it hardly used, in practice, though it was and is so powerful,
> in theory.
>
> That all being said, the thrust of this whole effort is to possibly
> advance Computer Science and language design, because in-between the
> purely concrete "object" architecture of the imperative programming
> languages and the purely abstract object architecture of
> object-oriented programming languages is a possible middle ground that
> could unite them all.
>
> Thank you for your time.
>
> Mark Janssen
> Tacoma, Washington
>