Dylan Design Notes

#5: Regularization of the Type System	(Change)
Copyright (c) 1993-1994, Apple Computer

Version 1, March 1993

This design note outlines a more expressive type system for Dylan.  
Not all types in Dylan are classes.  For example, singleton types 
are not classes.  The new type system allows for a variety of 
types, including classes and singleton types, and also provides a 
framework for introducing additional types that are not classes.

See Dylan Design Note #6: Limited Types, and Dylan Design Note #7: 
Union Types for descriptions of new Dylan types that are not 
classes.

-------------------------------------------------------------------

Add a new abstract class, <type>, to be the class of all objects 
that represent types, i.e. obey the type protocol described below.  
<class> and <singleton> are subclasses of <type> and behave the 
same as before.

An object can be an instance of an indefinite number of types, but 
object-class always returns a class.  The object is not an instance 
of any subclass of that class but it can be an instance of subtypes 
of that class that are not themselves classes.

The type protocol comprises the following:

 any type can be used as a parameter specializer
 (instance? object type ) tests type membership
 (subtype? type1 type2 ) tests type inclusion
 (make type ...) makes an instance (only allowed if the type is 
instantiable)
 Type objects are immutable
 If two type objects are equivalent and are not classes, it is 
unspecified whether they are id?.

The function subtype? replaces the existing function subclass?.  It 
is mathematically a partial ordering.  Type t1 is a subtype of type 
t2, i.e. (subtype? t1 t2) => true, if it is impossible to encounter 
an object that is an instance of t1 but not an instance of t2.  
Every type is a subtype of itself.  subtype? on classes is defined 
by inheritance.  If x is an object and t is a type, (subtype? 
(singleton x) t) iff (instance? x t).  Each proposed new type 
includes detailed rules for the behavior of subtype?.

-------------------------------------------------------------------

Notes:

We made this change because the existing Dylan type system was not 
sufficiently expressive for some of the things we want to do.  The 
two main needs for more expressive types are for documentation of 
the programmer's intent, and to enable more compiler optimization, 
especially for numeric code.  It would also be nice if the return 
type(s) of every function described in the Dylan book could be 
described in Dylan's type system; this is currently not the case.

This change was based on the following principles:

 All Dylan types may be used as method parameter specializers.

 All Dylan types are represented by first-class, anonymous 
objects.

 All operations on types are well-defined (for example, there is 
no Common Lisp-like freedom for subclass? to return don't know 
instead of an answer).

 We should add as few new names to Dylan as possible.

We needed to define the basic structure of types before we could 
coherently propose adding new types.  The class <type> exists 
because every protocol should have a corresponding abstract class 
so a method can be specialized to objects that support that 
protocol.  It makes sense to rename subclass? to subtype? for 
consistency.  The last bullet in the type protocol extends the 
existing statement (page 97) about singletons.

This design note does not define explicitly how users can define 
their own non-class types.  However, if the relevant classes and 
generic functions are not sealed, a user can define a subclass of 
<type> with methods for instance?, subtype?, and make.  This 
supports the entire Type Protocol with the exception of 
specializers; we could require specializers of user-defined classes 
to be implemented entirely in terms of the generic functions 
instance? and subtype?.  However, this design note does not require 
this.


