Dylan's type system
Scot Dyer
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...
Andrew LM Shalit
dy...@eagle.sharebase.com (Scot Dyer) wrote:
>
> 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
Kent Sandvik
>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
Kenneth Knight
>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 **