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

Discussion in 'Python' started by Uday S Reddy, Apr 17, 2013.

  1. Uday S Reddy

    Uday S Reddy Guest

    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

    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.

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

    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:
    Birmingham B15 2TT Web:
    Uday S Reddy, Apr 17, 2013
    1. Advertisements

  2. 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.
    88888 Dihedral, Apr 21, 2013
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page