[Prev][Next][Index][Thread]

Re: Dylan type-safety


At 4:56 PM -0400 7/23/99, Harry Chomsky wrote:
>Gregory T. Sullivan wrote in message ...
>>What the compiler chooses to do with that information is somewhat
>>open-ended.
>
>Does "open-ended" mean "not specified in the language definition"?  I.e.,
>one valid compiler might accept a piece of code while another (smarter)
>compiler might reject the same code as being non-type-safe?

The Dylan language is specified in terms of runtime behavior.  Warnings
generated by the compiler are not specified by the language definition.
They are considered to be part of the development environment.

That said, the culture of the Dylan is evolving in the direction of
the providing more and more compile time analysis and feedback.
People recognize its value.

...

>Again, I don't mean to be harshly critical of Dylan here, any more than I
>would criticize Smalltalk for the same kinds of problems.  I'm simply
>arguing that what Dylan provides isn't static type-safety as it's normally
>understood.  Or as Lyn A Headley put it in comp.lang.eiffel yesterday,
>"Maybe you guys have a different definition of static typing... I think
>Dylan has a distinctly dynamically-typed feel to it."

I would agree that Dylan has a dynamic feel to it, and I would agree
that many or most Dylan programs cannot be fully statically typed.
However, it is definitely the case that it is possible to write
Dylan programs that *are* fully statically typed.  Anyone who tells
you otherwise has not taken the time to learn the language.

Let's take a very simple example:

  define method add-two-integers (x :: <integer>, y :: <integer>)
    x + y;
  end method add-two-integers;

  define method attempt-the-impossible (z :: <list>)
    add-two-integers (z, z);
  end method attempt the impossible;

Two points about this example:

  The compiler can analyze add-two-integers, deduce the exact concrete
type of x and y, understand the set of available methods in the '+'
generic function, and inline the call to '+'.  This is possible because
the <integer> class is sealed, and so it cannot be given additional
subclasses, and because the '+' generic function is sealed over a
domain that includes <integer>.  In point of fact, Harlequin Dylan
makes this operation, and so integer arithmetic is often as efficient
as it is in C or Pascal or Assembly language.  This is true in spite
of the fact that <integer> is a full-fledged class and integers are
objects.  We don't take the Java shortcut, choosing instead to maintain
the consistency of our object model.

  Second point:  if this is your entire program, the compiler can deduce
that attempt-the-impossible will generate a type error.  It can understand
the type of z, it can understand that <list> and <integer> are disjoint,
and it can understand that there is only one method in the add-two-integers
generic function.  Harlequin Dylan will not refuse to compile the program
given above, but it will generate a serious warning when you compile it.
(Note: you'll still be able to run the program.  It may be that there are
other parts of the program that work fine, and that a type error in this
section shouldn't prevent you from testing the rest.)

  This type analysis is not rocket science.  Implementing it can be
more or less difficult, depending on how far you want to push things,
and what range of the language semantics you want to statically analyze.
But fundamentally, it is seems patently obvious that you can write
statically typed programs in Dylan.  If you disagree, we must have
different definitions of static typing, and perhaps you could let me
know what yours is.

  On the other hand, if you agree, perhaps you could forward this message
to those other news groups where people apparently don't understand
how Dylan works!

  -Andrew

p.s. give my regards to Thads if you talk to him.

--
Andrew Shalit                                    mailto:alms@folly.org
                                            http://www.folly.org/~alms
This is our garden, although we have no grass.
-Bahrije Baftiu, Kosavar refugee in Macedonia