Dylan's type system

[Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>]

Howdy who!

Dylan goes part way towards permitting the specification of types.
Unfortunately, in my opinion, it falls short.  In the name of
consistency, ease of use, type safety, and efficiency, Dylan should
provide a mechanism to specify the type of an object everytime an
object is declared.  (To all those that don't want to specify types,
power to you, I still want it to be optional.)  As it stands now, the
only time one can truly specify the type of an object is with the bind
construct.  There are many places where one would like to specify the
type of an object but is not allowed.  There is an ugly work around
that works in many cases and that involves using a new lexical
variable introduced and typed by bind.  Alas, this circumvents type
checking (among many other things).

I now state the places where one can't specify the type of an object
and suggest a syntax:

1. define

There is no way to specify the type of a module variable introduced
with define.

Suggested syntax:  (define (big-integer <integer>) 100000000)
Problem: Possible confusion with Scheme syntax?  Too bad.

2. non-specialized parameters

It would be nice to be able to specify the type of a parameter without
incurring the dispatch penalty.  Let's say that a parameter has the
same type in all the methods for a particular generic-function.  The
programmer really doesn't want to incur the overhead of specialization
for this parameter, because the specialization is really only
performing a kind of type-checking.  Perhaps there could be a flag (or
maybe sealing a class does this now) for turning off dispatching when
a parameter has only one specializer (where dispatching is really just
doing a kind of type-checking anyways).

Suggested syntax: ???

3. #key

There is no way to specify the type of a keyword parameter.  I
understand that there might be some confusion between a type and a
specialization and that it is difficult to use keyword parameters for
specialization, but this really falls short in terms of being able to
specify the types of the parameters.  In common-lisp, one can always
fall back on declare for these key parameters and non-specialized
parameters. 

Suggested syntax:  #key ((default <number>) 1) ... and all the combinations
Problem: Confusion with specialization... there must be a way!!!

4. #rest

There should be a way to specify the type of the rest parameters.  It
is silly to only be able to be able to specify the type of only the
number in the method +, for example.

Suggested syntax: #rest (numbers <number>)
Problem: Confusion with numbers being a <number>...

5. return types

There needs to be a way to specify return values in `define-method' AND 
`define-generic-function' because the return values might differ
in the methods of a given generic-function (i.e., they could be subclasses of
the return-values of the generic-function).  For users that want maximal 
efficiency and/or type-checking, it is crucial to provide a convenient mechanism
for specifying the return-values.

Suggested syntax: (define-method name (... #returns <integer>) ...) or
                  (define-method name (... #: <integer>) ...) 
Problem: still a bit heavy-handed

====

For efficiency's sake, it has proven very useful (in Sather) to be
able to specify that an object is precisely of a particular type, not
just a particular type or any of its subclasses.  By specifying the
exact type of an object, one can circumvent dispatching, which is
particularly expensive for accessing an object's slots in a
multiple-inheritance language (i.e., calculating the offset of a slot
each time it is referenced, even with caching).

One obvious implementation optimization (that is taken in Sather) is
to provide separate copies of each of the methods for each subclass of
each specializer where each specializer is replaced with an exact type
specification.  Although, this increases code size, it dramatically
improves performance.  (I could give an example if anyone was
interested.)

The previous optimization only works for parameters and it seems
crucial to have this precision with lexical variables as well.

Finally, now that Dylan has types, there are no rules for
type-checking.  For instance, what types of objects can someone
legally assign to another object of a given type.  How type-checking
for parameters and return-values?

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784864
bachrach@ircam.fr