Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!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; '(of': 0.07; '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; 'camp': 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:OOP': 0.16; 'subject:object': 0.16; 'subject:possible': 0.16; 'subject:programming': 0.16; 'subject:type': 0.16; 'subtype': 0.16; 'tradition': 0.16; 'types,': 0.16; 'underlying': 0.16; 'user-defined': 0.16; 'java,': 0.16; ':-)': 0.16; 'all.': 0.16; 'url:)': 0.16; 'language': 0.16; 'wrote:': 0.18; 'bit': 0.19; '(but': 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; 'cc:addr:python.org': 0.22; 'features,': 0.24; 'mathematical': 0.24; 'earlier': 0.24; 'fairly': 0.24; 'java': 0.24; "haven't": 0.24; 'question': 0.24; '>': 0.26; 'academic': 0.26; 'possibly': 0.26; 'subject:/': 0.26; 'url:edu': 0.26; 'header:In-Reply-To:1': 0.27; 'to:2**1': 0.27; 'correct': 0.29; 'generally': 0.29; 'ideal': 0.29; 'cc:2**2': 0.30; 'said,': 0.30; 'sets': 0.30; 'start,': 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; 'python).': 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; 'date:': 0.34; 'skip:d 20': 0.34; 'header:Reply-To:1': 0.67; 'promise': 0.68; 'research,': 0.68; 'reply-to:no real name:2**0': 0.71; 'obvious': 0.74; 'hoping': 0.75; 'power': 0.76; 'introduce': 0.78; '(ref:': 0.84; 'cook,': 0.84; 'describes': 0.84; 'e.g..': 0.84; 'hardly': 0.84; 'literature': 0.84; 'parser,': 0.84; 'received:65.55.111.72': 0.84; 'scala': 0.84; 'studying': 0.84; 'tended': 0.84; 'textbook': 0.84; 'thrust': 0.84; 'calculus': 0.91; 'washington': 0.93; 'reply-to:addr:live.com': 0.95; '2013': 0.98 X-EIP: [Kt6c5NMBrd+6Td1KB8/oWnIe9uzVHANwcT4u1cZuUFs=] X-Originating-Email: [moezadel@outlook.com] Content-Type: multipart/alternative; boundary="_2352a96f-70ee-4447-9ad0-4e5b8460f4be_" From: Moez AbdelGawad To: DeLesley Hutchins , Mark Janssen Subject: RE: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages Date: Mon, 15 Apr 2013 04:53:38 -0500 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 15 Apr 2013 09:53:39.0336 (UTC) FILETIME=[1AE95880:01CE39BF] Cc: Types List , Python List , Moez Abdel-Gawad X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: moezadel@live.com 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: 279 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1366019688 news.xs4all.nl 2609 [2001:888:2000:d::a6]:54950 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:43611 --_2352a96f-70ee-4447-9ad0-4e5b8460f4be_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= > Date: Sun=2C 14 Apr 2013 22:55:59 -0700 > From: delesley@gmail.com > To: dreamingforward@gmail.com > CC: types-list@lists.seas.upenn.edu=3B python-list@python.org > Subject: Re: [TYPES] The type/object distinction and possible synthesis o= f OOP and imperative programming languages >=20 > [ The Types Forum=2C http://lists.seas.upenn.edu/mailman/listinfo/types-l= ist ] >=20 > I'm not quite sure I understand your question=2C but I'll give it a shot.= :-) >=20 I'm in this same camp too :) > The C/C++ model=2C in which the types are anchored to the machine hardwar= e=2C > in the exception=2C not the rule. In the academic literature=2C "type t= heory" > is almost entirely focused on studying abstract models of computation tha= t > are purely mathematical=2C and bear no resemblance to the underlying > hardware. The lambda calculus is the most general=2C and most commonly u= sed > formalism=2C but there are many others=3B e.g. Featherweight Java provide= s a > formal model of objects and classes as they are used in Java. >=20 > "Types and Programming Languages"=2C by Benjamin Pierce=2C is an excellen= t > introductory textbook which describes how various language features=2C > including objects=2C can be formalized. If you are interested in OOP=2C = Abadi > and Cardelli's "Theory of Objects" is the obvious place to start=2C altho= ugh > I'd recommend reading Pierce's book first if you want to understand it. > :-) Abadi and Cardelli discuss both class-based languages=2C and pure > object languages. If you are interested in the type/object distinction i= n > particular=2C then I'll shamelessly plug my own thesis: "Pure Subtype > Systems" (available online)=2C which describes a formal model in which ty= pes > are objects=2C and objects are types. If you are familiar with the Self > language=2C then you can think of it as a type system for Self. >=20 Offering a different view=2C I'd like to (also=2C shamelessly) plug my own = thesis: "NOOP: A Mathematical Model of OOP" (available online) in which I d= enotationally model nominally-typed (ie=2C statically-typed class-based) OO= languages such as Java=2C C#=2C C++ and Scala (but not Python). In agreement with the most common tradition in PL research=2C types in NOOP= are modeled abstractly as (certain) sets (of objects). NOOP largely mimi= cs=2C for nominally-typed OO languages=2C what Cardelli=2C Cook=2C and othe= rs earlier did for structurally-typed OO languages. Regards=2C -Moez > Once you have a type system in place=2C it's usually fairly straightforwa= rd > to compile a language down to actual hardware. An interpreter=2C like th= at > used in Python=2C is generally needed only for untyped or "dynamic" > languages. There are various practical considerations -- memory layout= =2C > boxed or unboxed data types=2C garbage collection=2C etc. -- but the basi= c > techniques are described in any compiler textbook. Research in the areas > of "typed assembly languages" and "proof carrying code" are concerned wit= h > ensuring that the translation from high-level language to assembly langua= ge > is sound=2C and well-typed at all stages. >=20 > -DeLesley >=20 >=20 >=20 > On Sun=2C Apr 14=2C 2013 at 8:48 PM=2C Mark Janssen wrote: >=20 > > [ The Types Forum=2C http://lists.seas.upenn.edu/mailman/listinfo/types= -list] > > > > Hello=2C > > > > 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=2C Python's has migrated towards a "pure" Object > > model (ref: http://www.python.org/download/releases/2.2/descrintro/). > > Prior to then=2C 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" =2C it > > went towards Alan Kay's ideal of "everything is an object". From > > then=2C every user-defined class inherited from the abstract Object=2C > > rooted in nothing but a pure abstract ideal. The parser=2C lexer=2C an= d > > such spin these abstrations into something that can be run on the > > actual hardware. > > > > As a contrast=2C this is very distinct from C++=2C 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=2C > > for example=2C has many Container types=2C but each of them requires us= ing > > 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=2C 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=2C because as languages went higher and > > higher to this pure OOP model=2C the programmer+data ecosystem tended > > towards very personal object hierarchies because now the hardware no > > longer formed a common basis of interaction (note also=2C OOPs promise > > of re-usable code never materialized). > > > > It's not unlike LISP=2C where the power of its general language > > architecture tended towards hyperpersonal mini macro languages -- > > making it hardly used=2C in practice=2C though it was and is so powerfu= l=2C > > in theory. > > > > That all being said=2C the thrust of this whole effort is to possibly > > advance Computer Science and language design=2C 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=2C Washington > > >=20 =0A= = --_2352a96f-70ee-4447-9ad0-4e5b8460f4be_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A= =0A= =0A=


>=3B = Date: Sun=2C 14 Apr 2013 22:55:59 -0700
>=3B From: delesley@gmail.com<= br>>=3B To: dreamingforward@gmail.com
>=3B CC: types-list@lists.seas= .upenn.edu=3B python-list@python.org
>=3B Subject: Re: [TYPES] The typ= e/object distinction and possible synthesis of OOP and imperative programm= ing languages
>=3B
>=3B [ The Types Forum=2C http://lists.seas.u= penn.edu/mailman/listinfo/types-list ]
>=3B
>=3B I'm not quite s= ure I understand your question=2C but I'll give it a shot. :-)
>=3B <= br>
I'm in this same camp too :)

>=3B The C/C++ model=2C in whi= ch the types are anchored to the machine hardware=2C
>=3B in the excep= tion=2C not the rule. In the academic literature=2C "type theory"
>= =3B is almost entirely focused on studying abstract models of computation t= hat
>=3B are purely mathematical=2C and bear no resemblance to the und= erlying
>=3B hardware. The lambda calculus is the most general=2C and= most commonly used
>=3B formalism=2C but there are many others=3B e.g= . Featherweight Java provides a
>=3B formal model of objects and class= es as they are used in Java.
>=3B
>=3B "Types and Programming La= nguages"=2C by Benjamin Pierce=2C is an excellent
>=3B introductory te= xtbook which describes how various language features=2C
>=3B including= objects=2C can be formalized. If you are interested in OOP=2C Abadi
&g= t=3B and Cardelli's "Theory of Objects" is the obvious place to start=2C al= though
>=3B I'd recommend reading Pierce's book first if you want to u= nderstand it.
>=3B :-) Abadi and Cardelli discuss both class-based l= anguages=2C and pure
>=3B object languages. If you are interested in = the type/object distinction in
>=3B particular=2C then I'll shamelessl= y plug my own thesis: "Pure Subtype
>=3B Systems" (available online)= =2C which describes a formal model in which types
>=3B are objects=2C = and objects are types. If you are familiar with the Self
>=3B languag= e=2C then you can think of it as a type system for Self.
>=3B

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

In = agreement with the most common tradition in PL research=2C types in NOOP ar= e modeled abstractly as (certain) sets (of objects). =3B =3B NOOP l= argely mimics=2C for nominally-typed OO languages=2C what Cardelli=2C Cook= =2C and others earlier did for structurally-typed OO languages.

Rega= rds=2C

-Moez

>=3B Once you have a type system in place=2C i= t's usually fairly straightforward
>=3B to compile a language down to = actual hardware. An interpreter=2C like that
>=3B used in Python=2C i= s generally needed only for untyped or "dynamic"
>=3B languages. Ther= e are various practical considerations -- memory layout=2C
>=3B boxed = or unboxed data types=2C garbage collection=2C etc. -- but the basic
>= =3B techniques are described in any compiler textbook. Research in the are= as
>=3B of "typed assembly languages" and "proof carrying code" are co= ncerned with
>=3B ensuring that the translation from high-level langua= ge to assembly language
>=3B is sound=2C and well-typed at all stages.=
>=3B
>=3B -DeLesley
>=3B
>=3B
>=3B
>= =3B On Sun=2C Apr 14=2C 2013 at 8:48 PM=2C Mark Janssen <=3Bdreamingforwa= rd@gmail.com>=3Bwrote:
>=3B
>=3B >=3B [ The Types Forum=2C h= ttp://lists.seas.upenn.edu/mailman/listinfo/types-list]
>=3B >=3B>=3B >=3B Hello=2C
>=3B >=3B
>=3B >=3B I'm new to the li= st and hoping this might be the right place to
>=3B >=3B introduce s= omething that has provoked a bit of an argument in my
>=3B >=3B prog= ramming community.
>=3B >=3B
>=3B >=3B I'm from the Python pr= ogramming community. Python is an "interpreted"
>=3B >=3B language.= Since 2001=2C Python's has migrated towards a "pure" Object
>=3B >= =3B model (ref: http://www.python.org/download/releases/2.2/descrintro/).>=3B >=3B Prior to then=2C it had both types and classes and these ty= pes were
>=3B >=3B anchored to the underlying C code and the machine= /hardware
>=3B >=3B architecture itself. After the 2001 "type/class= unification" =2C it
>=3B >=3B went towards Alan Kay's ideal of "eve= rything is an object". From
>=3B >=3B then=2C every user-defined cl= ass inherited from the abstract Object=2C
>=3B >=3B rooted in nothin= g but a pure abstract ideal. The parser=2C lexer=2C and
>=3B >=3B s= uch spin these abstrations into something that can be run on the
>=3B = >=3B actual hardware.
>=3B >=3B
>=3B >=3B As a contrast=2C = this is very distinct from C++=2C where everything is
>=3B >=3B conc= retely rooted in the language's type model which in *itself* is
>=3B &= gt=3B rooted (from it's long history) in the CPU architecture. The STL=2C=
>=3B >=3B for example=2C has many Container types=2C but each of th= em requires using
>=3B >=3B a single concrete type for homogenous co= ntainers or uses machine
>=3B >=3B pointers to hold arbitrary items = in heterogeneous containers (caveat:
>=3B >=3B I haven't programmed = in C++ for a long time=2C so it's possible this
>=3B >=3B might not = be correct anymore).
>=3B >=3B
>=3B >=3B My question is: Is = there something in the Computer Science literature
>=3B >=3B that ha= s noticed this distinction/development in programming language
>=3B &g= t=3B design and history?
>=3B >=3B
>=3B >=3B It's very signif= icant to me=2C because as languages went higher and
>=3B >=3B higher= to this pure OOP model=2C the programmer+data ecosystem tended
>=3B &= gt=3B towards very personal object hierarchies because now the hardware no<= br>>=3B >=3B longer formed a common basis of interaction (note also=2C = OOPs promise
>=3B >=3B of re-usable code never materialized).
>= =3B >=3B
>=3B >=3B It's not unlike LISP=2C where the power of its = general language
>=3B >=3B architecture tended towards hyperpersonal= mini macro languages --
>=3B >=3B making it hardly used=2C in pract= ice=2C though it was and is so powerful=2C
>=3B >=3B in theory.
&= gt=3B >=3B
>=3B >=3B That all being said=2C the thrust of this who= le effort is to possibly
>=3B >=3B advance Computer Science and lang= uage design=2C because in-between the
>=3B >=3B purely concrete "obj= ect" architecture of the imperative programming
>=3B >=3B languages = and the purely abstract object architecture of
>=3B >=3B object-orie= nted programming languages is a possible middle ground that
>=3B >= =3B could unite them all.
>=3B >=3B
>=3B >=3B Thank you for y= our time.
>=3B >=3B
>=3B >=3B Mark Janssen
>=3B >=3B T= acoma=2C Washington
>=3B >=3B
>=3B
=0A=
= --_2352a96f-70ee-4447-9ad0-4e5b8460f4be_--