Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!know!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!unixhub!shelby!neon!craig
From: craig@Neon.Stanford.EDU (Craig D. Chambers)
Newsgroups: comp.object
Subject: Re: Void references
Message-ID: <1990Nov12.011704.28141@Neon.Stanford.EDU>
Date: 12 Nov 90 01:17:04 GMT
References: <447@eiffel.UUCP> <77500064@m.cs.uiuc.edu> <451@eiffel.UUCP>
Organization: Stanford University
Lines: 77

In article <451@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>
>There is something strange in this discussion. In the messages
>by Ralph Johnson and Craig Chambers one gets the impression
>(please correct me if this is a wrong impression) that
>it is possible to guarantee statically that no error will
>ever occur at run-time.

You are so corrected.  I'm not making such a claim (in fact, in my
earlier posting I presented concrete examples that are extremely
difficult to type check statically, let alone verify for
"correctness"), and I'm certain that Ralph Johnson isn't making such a
claim, either.  Again, give us some credit.

> [stuff deleted]
>
>1. Full-fledged program proving.
>2. Unacceptable restrictions on the expressive power
>   of the language (e.g. no references).
> 
> [stuff deleted]
>
> x.f
>
> [stuff deleted]
>
>Then the only problem of software reliability becomes:
>
>/A/
>	Can we statically guarantee that for every possible execution
>	of x.f at run time, x will be attached to an object capable
>	of handling feature f?
>
>Because answering this question positively would require either
>or both of 1. and 2. above and hence seems impossible, the most
>useful practical solution seems to be to settle for the question
>
>/B/
>	Can we statically guarantee that for every possible execution
>	of x.f at run time, if x is attached to an object, that object
>	will be capable of handling feature f?

Why do you insist that void references are required?  I've given you
examples of languages that include neither void references nor generic
nil objects (CLU, Trellis/Owl), and real programs can be written in
them.  Implementations of both are available on various platforms
(although I think you probably have to pay money to DEC for
Trellis/Owl).  Can you present examples that *require* void references
to be practical?  I can think of a few examples that without void
references may be a little uglier or require a slightly more
sophisticated type checker, but allowing void references throughout a
program introduces a potential class of programming errors that is
much more costly that a bit of complexity in a few instances.

My position is that static type checking may be useful for developing
large, reliable systems.  It is certainly not *the* solution, but may
be one of several useful programming tools.  I feel that static type
checking, if it exists, should be as unrestrictive as possible
*without* accepting without notice programs that contain what I would
call type errors.  [I know what I mean by "type error", but I don't
have the time or inclination to define it completely here.]  To me,
this implies contravariant subtyping rules, support for multiple
dispatching, and (as a last resort) the ability of the programmer to
ignore compile-time type errors (of course the implementation will
contain a run-time type test at every ignored type error).  I consider
void references to be an undesirable language feature, since they are
difficult to check statically (thus reducing the reliability of
programs) and offer little additional expressive power in return.  I
agree with most people that subtyping is different from implementation
inheritance, and that the two mechanisms should be linguistically
distinct.  This doesn't necessarily imply that classes cannot be
interpreted as both types and chunks of code, but instead that at
least two kinds of subclassing (subtyping and code inheritance) should
be supported.  I hope that clears up any mistaken impressions of my
position.

-- Craig Chambers