Dylan Design Notes

#13: Type Restrictions Survive Assignment	(Change)

Version 1, March 1993
Copyright (c) 1993-1994, Apple Computer

When a parameter or local variable is specialized, its initial value 
is required to be an instance of a certain type.  This design note 
extends the type restriction to cover values later stored into the 
specialized parameter or local variable.

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

Specify that when a parameter or local variable is specialized, any 
value stored into the parameter or local variable must be of the type 
of the specializer.  Further specify that a type error is signaled if 
any program attempts to store a value of the wrong type into a 
specialized parameter or local variable.

The following example was legal in the previous Dylan specification.  
In the new specification, it results in an error being signaled.

((method ((n <integer>))
    (when (< n 0)
      (set! n #f))
    n)
 -50)

The code could be rewritten to legal Dylan as:

(method ((n <integer>))
   (bind ((result n))
     (when (< result 0)
       (set! result #f))
    result)
or
(method ((n <integer>))
   (if (< n 0) #f n))


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

Notes:

This change allows the type of the variable to be known at all times, 
whether or not it has been assigned.   This information can 
potentially help both programmers and compilers.  Programmers used to 
static languages will expect this behavior and find it useful.

Run-time type checks need be inserted only on variable assignments 
(fetches), rather than variable references (stores).  Because 
references outnumber variable assignments in most programs, this 
change might allow many type checks when referencing to be skipped.

A smart compiler can do the type-check at compile-time in many cases, 
reporting errors at compile-time and generating better code.
