Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages

Reply
Thread Tools

Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages

 
 
Uday S Reddy
Guest
Posts: n/a
 
      04-17-2013
Mark Janssen writes:

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

>
> I like that word "storage type", it makes it much clearer what one is
> referring to.


Indeed. However, this is not the only notion of type in imperative
programming languages. For example, a function type in C or its descendants
is not there to describe storage, but to describe the interface of an
abstraction. I will use Reynolds's term "phrase types" to refer to such
types. Reynolds's main point in "The Essence of Algol" was to say that
phrase types are much more general, and a language can be built around them
in a streamlined way. Perhaps "Streamlining Algol" would have been a more
descriptive title for his paper. Nobody should be designing an imperative
programming language without having read "The Essence of Algol", but they
do.

Whether storage types (and their generalization, class types) should be
there in a type system at all is an open question. I can think of arguments
both ways. In Java, classes are types. So are interfaces (i.e., phrase
types). I think Java does a pretty good job of combining the two
in a harmonious way.

If you have trouble getting hold of "The Essence of Algol", please write to
me privately and I can send you a scanned copy. The Handout 5B in my
"Principles of Programming Languages" lecture notes is a quick summary of
the Reynolds's type system.

http://www.cs.bham.ac.uk/~udr/popl/index.html

> I feel like I'm having to "come up to speed" of the academic
> community, but wonder how and why this large chasm happened between
> the applied community and the theoretical. In my mind, despite the
> ideals of academia, students graduate and they inevitably come to work
> on Turing machines of some kind (Intel hardware, for example,
> currently dominates). If this is not in some way part of some
> "ideal", why did the business community adopt and deploy these most
> successfully? Or is it, in some *a priori* way, not possible to apply
> the abstract notions in academia into the real-world?


The chasms are too many, not only between theoretical and applied
communities, but within each of them. My feeling is that this is
inevitable. Our field progresses too fast for people to sit back, take
stock of what we have and reconcile the multiple points of view.

There is nothing wrong with "Turing machines". But the question in
programming language design is how to integrate the Turing machine concepts
with all the other abstractions we need (functions/procedures, modules,
abstract data types etc.), i.e., how to fit the Turing machine concepts into
the "big picture". That is not an easy question to resolve, and there isn't
a single way of doing it. So you see multiple approaches being used in the
practical programming languages, some cleaner than the others.

The abstract notions of academia do make it into the real world, but rather
more slowly than one would hope. Taking Java for example, the initial
versions of Java treated interfaces in a half-hearted way, ignored
generics/polymorphism, and ignored higher-order functions. But all of them
are slowly making their way into Java, with pressure not only from the
academic community but also through competition from other "practical"
languages like Python, C# and Scala. If this kind of progress continues,
that is the best we can hope for in a fast-paced field like ours.

Cheers,
Uday Reddy

--
Prof. Uday Reddy Tel: +44 121 414 2740
Professor of Computer Science Fax: +44 121 414 4281
School of Computer Science
University of Birmingham Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
Edgbaston
Birmingham B15 2TT Web: http://www.cs.bham.ac.uk/~udr
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      04-21-2013
Uday S Reddy於 2013年4月17日星期三UTC+8下午5時10分58秒 寫道:
> Mark Janssen writes:
>
>
>
> > > 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.

>
> >

The imperative part is supported in Python by tuples only.
The name binding assignment of an object is perative in Python.

Anyway it is not so difficult to mimic the behaviors
and to gain the benefits of imperative languages
at least in the c-python implementation by those
who can play with the Python language in programming.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Ian Kelly Python 0 04-16-2013 11:52 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Mark Janssen Python 0 04-16-2013 11:40 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Mark Janssen Python 0 04-16-2013 11:16 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Matthias Felleisen Python 0 04-15-2013 01:50 PM
Re: [TYPES] The type/object distinction and possible synthesis of OOPand imperative programming languages Uday S Reddy Python 0 04-15-2013 09:06 AM



Advertisments