types (was: ARGON)

Jecel Assumpcao Jr jecel@lsi.usp.br
Mon, 30 Dec 1996 01:55:13 -0200


Alaric B. Williams wrote:
> 
> On 20 Dec 96 at 1:01, Sean 'Captain Napalm' Conner wrote:
> >   In the January 1986 issue of "Computer Language" there's an article on
> > KISS, which, as far as I know, only exists in this article.  The declaration
> > of variables (traditional, numbers and strings) is as follows:
> >
> >       :       means "means" or "defined as"
> >       ..      means range
> >       ,       logical AND
> >       ;       logical OR
> >       @       valid digit
> >       $       valid character
> 
> Eurgh - it's a COBOL picture! :-)
> 
> Seriously, though, seems an interesting idea. I'll think on it.

Sorry this is so late, but I hope it will help you think
about this.

Smalltalk-80 originally used 15 bit integers for most
math, then moved to 31 bits on the Vax (though 30 bits
are more common now). No programs had to be rewritten
and nothing broke in all these changes. Isn't this the
kind of thing we want?

David Ungar described how the concept of types became
more complicated after objects arrived. He talks about
to different kinds of types, which are almost always
mixed up:

     1) concrete types
            - help the compiler generate code
            - don't help the programmer
            - low level

     2) abstract types
            - help the programmer verify correctness
            - don't help the compiler
            - high level

Concrete types are about memory layouts and machine
instructions, while abstract types are normally called
"protocols" or "interfaces" or something like that.

Self hides concrete types entirely in the implementation
and doesn't have abstract types at all (though they could
be added at the user level, without modifying the
virtual machine).

C++ makes classes the same thing as concrete types, as
long as you don't use "virtual" in your programs. If
you do, you introduce a very limited variant of abstract
types. They used "super class prefixing" to make it
work like concrete types as much as possible, with mixed
results. The problem is that polymorphism is very restricted
(classes must be "related" for code to work) so they
patched things up by introducing multiple inheritence
(so previously unrelated classes could now become related).
Unfortunately, prefixing is terribly distorted by trying
to adapt it to handle multiple inheritence. And this in
such a way that makes all C++ compilers incompatible with
each other.

Leaving out abstract types leads us to the infamous
"message not understood" problems of Self and Smalltalk.
But mixing up the kinds of types and putting concrete
types (COBOL pictures) in the language definition makes
the programmer do the compiler's job. I advise against
it.

-- Jecel