Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore-2!bellcore!maya!caseau
From: caseau@maya.bellcore.com (Yves J Caseau)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <27222@bellcore.bellcore.com>
Date: 26 Sep 90 13:32:41 GMT
References: <0yw10qr@Unify.Com> <411@eiffel.UUCP> <736@tetrauk.UUCP>
Sender: news@bellcore.bellcore.com
Reply-To: caseau@maya.UUCP (Yves J Caseau)
Organization: Bell Communications Research, Morristown NJ
Lines: 32

Previous postings assumed that classes and types, although different, could
be assimilated for the sake of compiler technology. I don't agree with that, 
there are many reasons why a type system should supersede the class taxonomy:

  - The union of some classes is not always a class, so an explicit union
    type is needed (see Johnson & al's work on TS optimizer for more 
    detailed explanations).
 
  - Set operations need "list/set_of_X" kind of constructs, which are not 
    usually in the class taxonomy (unless you have genericity). The type 
    system should infer the type of [[1 cons ()] car] as being "integer", you
    need a better type system to achieve this.

  - A certain amount of polymorphism is necessary (the famous stack_of_X 
    example), which also requires an extended type system if the compiler is 
    supposed to remove the overhead due to the high-level specification.
    In other words, it is easy to implement a stack_of_something with
    SMALLTALK, it is more difficult to compile this implementation into a
    very good code (without useless dynamic "type" checking).

  - Optimizations based on constant recognition may be directly supported
    by an extended type system.

There are many good papers explaining why an extended type system is necessary
(see POPL of this year). In the LAURE language, we have found it necessary to
quit identifiying classes and types to produce "really smart" code. My 
experience is that you need types in a high-level, nice, .... object-oriented
language to gain safety and *efficiency*.  


-- Yves Caseau
   caseau@bellcore.com