Previous chapter: #12: Size-Setter for Stretchy Sequences (Addition)

Dylan Design Notes: #13: Type Restrictions Survive Assignment (Change)

Dylan Design Notes

#13: Type Restrictions Survive Assignment (Change)

Version 1, March 1993

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.

Next chapter: #14: Union Allows Duplicates (Clarification)