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

Re: Dylan type-safety

Thanks for the thorough reply.  Let me make sure I understand everything
you're saying correctly:

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?

>Alternatively, the compiler may deduce that all possible
>values of b will _not_ be an instance of <foo>;  in which case a
>compile time error would be signalled.

So should the compiler signal an error if it can prove that _some_ execution
path will yield a value not of type <foo>, or only if it can prove that
_every_ execution path will yield a value not of type foo?  Is it even
realistic to try to prove such a thing in a language with multiple
inheritance, where a value may simultaneously conform to several unrelated
types?  That is, even if b is declared to be of unrelated type <bar>, its
value could be of a common subtype <foobar>.  I don't see how a compiler
could ever prove that the value of b will _not_ conform to <foo>, even
assuming just a single execution path.  (I suppose it could prove it if it
could trace the construction of the value all the way back to the underlying
make call and ensure that this make wasn't overloaded; but I don't think
that's feasible in most cases.)

>If the compiler
>indicates all points where either a type check or a possibly-failing
>dynamic dispatch occur, then code which has none of these points could
>legitimately be called "statically type correct".

Do you think that most real-world Dylan code is statically type correct in
this sense?  Is this a concept that Dylan programmers care about?

>Harlequin Dylan has a similar feature -- code coloring (see View/Color
>Dispatch Optimizations) in the HD Editor.  This technically colors
>code according to optimizations applied to call sites.  Since code
>cannot be directly called or inlined if there is a possibility of
>dispatch failure, an "optimized" call site can be viewed as type
>correct.

Interesting.  Are there common cases of code that is provably type-correct
but can't be optimized in this way?  I would guess that there are.  If so,
it would be unreasonable for a project leader to insist that all the code in
the project satisfy this "color-test".  Such insistence would probably
prevent programmers from using common OO paradigms.  In other words,
optimization is a sufficient but not necessary condition for type-safety, so
it's not always a useful way to check whether your code is type-safe.

Also, in cases where there's an error, this technique would localize it
incorrectly.  In my bird/penguin/flying example, it's not wrong to call
fly(bird) when bird is of type <penguin> -- after all, bird is of type
<bird> and there's a fly generic function on <bird>.  What's really wrong is
to declare the type <penguin> but fail to define a fly method for it.
Traditional OO languages would catch this error easily and identify it as a
problem with the <penguin> class.  But it seems that Dylan doesn't really
consider this an error, and if you coax the compiler into calling it an
error, it will say that the error is in the call to fly(bird) (which may be
in an entirely different module, written by a different programmer, who now
must dig into the definitions of <bird> and <penguin> and the fly generic
function to figure out what went wrong).

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."
References: