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

Now that all that fuss is over (about multiple-argument dispatch), I think
there's a real Dylan design issue to be brought up.

What made the early fortrans so easy to compile was exactly what made them so
difficult to use in many cases -- a real lack of dynamicism.  On the other
hand, if we look at LISP around that time, we see that it was problematic in
exactly the opposite way -- a real lack of static-ness.

In my eyes, good languages provide a facility for dynamicism that a compiler
can reduce to static stuff as much as possible.  This is certainly the [only]
argument for C++ over Smalltalk, since they both subscribe to [basically] the
same paradigm otherwise.

THE PROBLEM:

The s-expression "(car x)" cannot be typed by a Dylan compiler, even given that
x is an instance of <list>.  Therefore, the s-expression "(f (car x))" MUST
be compiled as code using a dynamic method dispatch.  If we had some higher
order type information, like x is a <list> of <integer>s, then the <integer>
method for f could be selected statically (at compile-time -- actually this
would be a mere constant reduction in the front-end...).

This is a real liability of Dylan's, and in my mind the only major design flaw.
Are there any plans to introduce a higher-order class system to Dylan?  Of
course, a "sufficiently smart compiler" could _view_ <list> as higher-order
and do all kinds of inter-procedural analysis to get the higher-order type
information, but this probably wouldn't come to fruition -- like most of the
other "sufficiently smart" LISP compilers...

Are there any plans to add higher-order classes to the Dylan spec?  I could
probably do it with the existing Dylan language*, but that wouldn't make my
compiler know about them so what would be the use?

        -- Scot

* By writing a function: (<list-of> /class/) that returns a class from a hash-
table, since method specializers have to be eval'ed anyhoo...



Sun, 10 Sep 1995 17:34:57 GMT  
 Dylan's type system

Quote:

> Are there any plans to add higher-order classes to the Dylan spec?

Yes.  The specification of this feature should be available shortly.

  -Andrew Shalit
   Apple Computer



Mon, 11 Sep 1995 04:25:12 GMT  
 Dylan's type system

Quote:
>In my eyes, good languages provide a facility for dynamicism that a compiler
>can reduce to static stuff as much as possible.  This is certainly the [only]
>argument for C++ over SmallTalk, since they both subscribe to [basically] the
>same paradigm otherwise.

I saw a compiler implementation as part of a new language I'm not allowed
to talk
about (it's not from Apple) where the static compiler part does *no* type or
parameter checking, but the runtime catches the most obvious problems.

Now, first I thought this was heresy, but the more I think about this
angle it makes sense concerning having an extremely fast static compiler
in combination with a debug-runtime environment for testing purposes.

By the way, I'm not a static language evangelist, quite the contrary.

Regards,
Kent Sandvik



Mon, 11 Sep 1995 03:46:41 GMT  
 Dylan's type system

Quote:

>THE PROBLEM:

>The s-expression "(car x)" cannot be typed by a Dylan compiler, even given that
>x is an instance of <list>.  Therefore, the s-expression "(f (car x))" MUST
>be compiled as code using a dynamic method dispatch.  If we had some higher
>order type information, like x is a <list> of <integer>s, then the <integer>
>method for f could be selected statically (at compile-time -- actually this
>would be a mere constant reduction in the front-end...).

I think I must be missing something here. If x is an instance of <list> the
compiler will know this. Are you asking for sub-classes of <list> like
<integer-list> which you as the programmer must specify when instantiating
x in the first place? Or, and this sounds like a better though tougher idea,
if x is always a <list> of <integer>s as you said the compiler would
optimize its code generation around this fact? This latter sounds like it
would be really tricky. What am I mis-understanding?

  ** Ken **



Tue, 12 Sep 1995 05:07:31 GMT  
 
 [ 4 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