Dylan's type system 
Author Message
 Dylan's type system

(On the topic of higher-order typing)

Some functions (like map) have attractive type disciplines.  Imagine:

(Define-Method (Map (F (<Function> #<Alpha> #<Beta>)) (L (<List-Of> #<Alpha>)))
 (If (Null? L) '() (Cons (F (Car L)) (Map F (Cdr L)))))

Where <Function> and <List-of> are HIGHER ORDER CLASSES.  This says, basically
that the function map applied to a function from some type "alpha" to another
type "beta" and a list of elements of the same type "alpha" yields a list of
elements of the same type "beta."  (Actually the return type would have to be
derived by a dylan compiler)

The key here (for me) is that Dylan EVAL's the class specializers in a define-0
method form, so why not call a function? (like <list-of>...?)

Most lists are not heterogenous.  Of course, a completely heterogenous list
could be described as a list of elements of type <object>...

        -- Scot

P.S.  The idea here is not to remove Dylan's dynamicism -- only to produce
efficient executable images where un-used dynamicism in the program being
compiled can be recognised and removed.  This is just constant reduction,
except with type information and method-dispatch information...  Nothing that
new to the compiler world...



Sat, 14 Oct 1995 20:01:42 GMT  
 Dylan's type system
Actually, on further reading of some of the type stuff in the design notes, I'm
not 100% sure that paramaterised types aren't already there; I'm rather confused
as to when type specifiers are evaluated.

The example in the note specifying results seems to require call-time evaluation
to determine the right type:
(define-method always (object #values function)
   (method (#rest ignored
            #values (object (object-type object)))
      object))

Since '(object-type object) can only be evaluated when 'object is live, the
check is in general impossible to optimise away. Also, if the values type-spec
can only be determined at run-time, it would seem to imply that any type-spec
can be evaluated at run-time; I guess that this can't be right, as it would
make dispatch potentially non-deterministic.

Am I reading too much into this one example?

Simon



Sun, 15 Oct 1995 06:02:46 GMT  
 Dylan's type system

Quote:
> Date: Tue, 27 Apr 93 18:02:46 -0400

> Actually, on further reading of some of the type stuff in the design notes, I'm
> not 100% sure that paramaterised types aren't already there; I'm rather confused
> as to when type specifiers are evaluated.

The parameter specializers and value types are evaluated at the time the method is
defined, as documented in the design note.

Quote:
> The example in the note specifying results seems to require call-time evaluation
> to determine the right type:
> (define-method always (object #values function)
>    (method (#rest ignored
>             #values (object (object-type object)))
>       object))

> Since '(object-type object) can only be evaluated when 'object is live, the
> check is in general impossible to optimise away. Also, if the values type-spec
> can only be determined at run-time, it would seem to imply that any type-spec
> can be evaluated at run-time; I guess that this can't be right, as it would
> make dispatch potentially non-deterministic.

> Am I reading too much into this one example?

You might be confused by the fact that there are two methods in this example.  
There is a method for the generic function always, whose body creates and returns
a second method, which is a closure over the value of the local variable object
which contains an argument to the first method.

The value type expression in the second method is evaluated once when that method
is created (during a call to always); it is not evaluated each time that method is
called.

There is no problem with non-deterministic dispatch since a parameter specializer
expression is evaluated once when a method is created, which is obviously before
the method is added to a generic function.



Sun, 15 Oct 1995 02:25:40 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. An Attempt to Formalise Dylan's Type System (Part 2)

2. An Attempt to Formalise Dylan's Type System (Part 1)

3. Dylan's type system

4. Difference between a type system and a type constraint system

5. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

6. Difference between a type system and a type constraint system

7. Miranda's Type System

8. Biff's-own-guide to type systems?

9. type systems and #f and '()

10. Visual Prolog's type system

11. Papers/Info on Type Systems/Type Theory ?

12. Types-SIG: Special Interest Group on the Python type system

 

 
Powered by phpBB® Forum Software