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

[Moez AbdelGawad]

> Date: Sun, 14 Apr 2013 22:55:59 -0700
> From: delesley at gmail.com
> To: dreamingforward at gmail.com
> CC: types-list at lists.seas.upenn.edu; python-list at python.org
> Subject: Re: [TYPES] The type/object distinction and possible synthesis of  OOP and imperative programming languages
> 
> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
> 
> I'm not quite sure I understand your question, but I'll give it a shot.  :-)
> 

I'm in this same camp too :)

> 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.
> 

Offering a different view, I'd like to (also, shamelessly) plug my own thesis: "NOOP: A Mathematical Model of OOP" (available online) in which I denotationally model nominally-typed (ie, statically-typed class-based) OO languages such as Java, C#, C++ and Scala (but not Python).

In agreement with the most common tradition in PL research, types in NOOP are modeled abstractly as (certain) sets (of objects).   NOOP largely mimics, for nominally-typed OO languages, what Cardelli, Cook, and others earlier did for structurally-typed OO languages.

Regards,

-Moez

> 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
> >
>