Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'python,': 0.02; 'subject:: [': 0.04; 'languages,': 0.04; 'languages.': 0.04; 'argument': 0.05; 'model,': 0.05; 'c++,': 0.07; 'compiler': 0.07; 'practice,': 0.07; 'advance': 0.07; 'code"': 0.09; 'exception,': 0.09; 'high- level': 0.09; 'inherited': 0.09; 'objects,': 0.09; 'oop': 0.09; 'oop,': 0.09; 'plug': 0.09; 'pointers': 0.09; 'url:releases': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'language,': 0.12; 'translation': 0.12; 'url:download': 0.12; 'itself.': 0.14; 'language.': 0.14; '(note': 0.16; '2001,': 0.16; 'benjamin': 0.16; 'c/c++': 0.16; 'cc:name:python list': 0.16; 'containers': 0.16; 'distinct': 0.16; 'ecosystem': 0.16; 'garbage': 0.16; 'hardware.': 0.16; 'ideal.': 0.16; 'interpreter,': 0.16; 'janssen': 0.16; 'java.': 0.16; 'lambda': 0.16; 'layout,': 0.16; 'lisp,': 0.16; 'literature,': 0.16; 're-usable': 0.16; 'rule.': 0.16; 'shot.': 0.16; 'sound,': 0.16; 'subject: \n ': 0.16; 'subject:OOP': 0.16; 'subject:object': 0.16; 'subject:possible': 0.16; 'subject:programming': 0.16; 'subject:type': 0.16; 'subtype': 0.16; 'types,': 0.16; 'underlying': 0.16; 'user-defined': 0.16; ':-)': 0.16; 'all.': 0.16; 'url:)': 0.16; 'language': 0.16; 'wrote:': 0.18; 'bit': 0.19; '2001': 0.19; "python's": 0.19; 'unlike': 0.19; 'subject:] ': 0.20; 'machine': 0.22; 'memory': 0.22; 'programming': 0.22; 'community.': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'cc:2**1': 0.23; 'features,': 0.24; '\xa0if': 0.24; 'fairly': 0.24; 'java': 0.24; "haven't": 0.24; 'question': 0.24; 'cc:no real name:2**0': 0.24; 'academic': 0.26; 'possibly': 0.26; 'subject:/': 0.26; 'url:edu': 0.26; 'header:In-Reply-To:1': 0.27; 'correct': 0.29; 'generally': 0.29; 'ideal': 0.29; 'said,': 0.30; 'start,': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'url:mailman': 0.30; 'went': 0.31; 'code': 0.31; 'towards': 0.31; 'usually': 0.31; 'alan': 0.31; 'commonly': 0.31; 'container': 0.31; 'contrast,': 0.31; 'formed': 0.31; 'mini': 0.31; 'purely': 0.31; 'types.': 0.31; 'class': 0.32; 'languages': 0.32; 'run': 0.32; 'quite': 0.32; 'url:python': 0.33; 'entirely': 0.33; 'used,': 0.33; 'actual': 0.34; 'noticed': 0.34; 'skip:d 20': 0.34; "i'd": 0.34; 'could': 0.34; 'basic': 0.35; 'classes': 0.35; 'common': 0.35; 'something': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'interaction': 0.36; 'object,': 0.36; 'to:addr:gmail.com': 0.65; 'techniques': 0.66; 'promise': 0.68; 'obvious': 0.74; 'hoping': 0.75; 'power': 0.76; 'introduce': 0.78; '(ref:': 0.84; 'describes': 0.84; 'hardly': 0.84; 'literature': 0.84; 'parser,': 0.84; 'studying': 0.84; 'tended': 0.84; 'textbook': 0.84; 'thrust': 0.84; 'calculus': 0.91; '\xa0there': 0.91; 'washington': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SSt6vrSd/kVHBC5oXTEYszB5VWICAI0G6qCep+bx1Dc=; b=OKyH0xoe0dEpyH8a+/NtmdTxikgzKTdRh1RRXPIjHEUwBIqrPMfhPf1zK7MkIXS7NE s4EHZGSZ3Ydy1qIPRkU0nAbgIJW6ujt8YmHwYp24rNEgkh2RSpbU3z7wKbkm09FMVcaN +U9L3HY4R03yooxo7gKrx2pCp/vNQMj53g8zaUmrSF8vw5ULQujqxqbNwV3EOtvO7LDj tSkXBKNtBzfj0RAGczIvQA7eYv17K8YqckWLXES/jnZdzPTfcpTHbCAfJG27hB5Ovagt eCuBJxuFjDXNkco95FSuGA4fBdVesCq0ZO3we1BvKNg03RqqlKm/dkl3PaZLUEp7G+th 6Shw== MIME-Version: 1.0 X-Received: by 10.59.5.226 with SMTP id cp2mr15204569ved.13.1366005359728; Sun, 14 Apr 2013 22:55:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Apr 2013 22:55:59 -0700 Subject: Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages From: DeLesley Hutchins To: Mark Janssen Content-Type: multipart/alternative; boundary=047d7ba96cf83a611c04da5fe89e Cc: types-list@lists.seas.upenn.edu, Python List X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 210 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1366005367 news.xs4all.nl 2588 [2001:888:2000:d::a6]:58795 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:43605 --047d7ba96cf83a611c04da5fe89e Content-Type: text/plain; charset=ISO-8859-1 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 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 > --047d7ba96cf83a611c04da5fe89e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm not quite sure I underst= and your question, but I'll give it a shot. =A0:-)

= The C/C++ model, in which the types are anchored to the machine hardware, i= n the exception, not the rule. =A0In the academic literature, =A0"type= theory" is almost entirely focused on studying abstract models of com= putation that are purely mathematical, and bear no resemblance to the under= lying hardware. =A0The lambda calculus is the most general, and most common= ly used formalism, but there are many others; e.g. Featherweight Java provi= des 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. =A0If= you are interested in OOP, Abadi and Cardelli's "Theory of Object= s" is the obvious place to start, although I'd recommend reading P= ierce's book first if you want to understand it. =A0:-) =A0Abadi and Ca= rdelli discuss both class-based languages, and pure object languages. =A0If= you are interested in the type/object distinction in particular, then I= 9;ll shamelessly plug my own thesis: "Pure Subtype Systems" (avai= lable online), which describes a formal model in which types are objects, a= nd objects are types. =A0If you are familiar with the Self language, then y= ou can think of it as a type system for Self.

Once you have a type system in place, it= 9;s usually fairly straightforward to compile a language down to actual har= dware. =A0An interpreter, like that used in Python, is generally needed onl= y for untyped or "dynamic" languages. =A0There are various practi= cal considerations -- memory layout, boxed or unboxed data types, garbage c= ollection, etc. -- but the basic techniques are described in any compiler t= extbook. =A0Research in the areas of "typed assembly languages" a= nd "proof carrying code" are concerned with ensuring that the tra= nslation from high-level language to assembly language is sound, and well-t= yped at all stages. =A0

=A0 -DeLesley



On Sun, Ap= r 14, 2013 at 8:48 PM, Mark Janssen <dreamingforward@gmail.com= > wrote:
[ The Types Forum, http://lists.s= eas.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. =A0Python is an "interp= reted"
language. =A0Since 2001, Python's has migrated towards a "pure&quo= t; Object
model (ref: http://www.python.org/download/releases/2.2/descrint= ro/).
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. =A0After the 2001 "type/class unification" ,= it
went towards Alan Kay's ideal of "everything is an object". = =A0From
then, every user-defined class inherited from the abstract Object,
rooted in nothing but a pure abstract ideal. =A0The 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. =A0 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<= br> might not be correct anymore).

My question is: =A0Is 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 programmi= ng
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

--047d7ba96cf83a611c04da5fe89e--