Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Thu, 13 Aug 1998, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > I think if you keep type information around at run time, you've sacrificed 
> > some optimization, right?
> 
> I don't think so.  For example, consider "Mumble(T'Class(X));" in Ada,
> or X.Mumble in Eiffel.  Both dispatch to the appropriate implementation
> of Mumble at run time, and both need to have "type information" around
> at run time to do so. 

But if T'Class(X), or X, can be determined to only be of one type by the 
compiler, keeping the tag around at run time is potentially less optimal 
than eliminating it. Thats what I was talking about, eliminating all of 
the tags that you can, rather tthan schlepping them around. 

> > I agree that Eiffel's built in assertion mechanisms are very nice, and
> > more powerful than what we have in Ada. I also think that external tools 
> > could provide many of the same advantages, and maybe even provide more.
> 
> I'd be interested in seeing a design for such external tools.

The Larch toolkit is one attempt, though it seems that there is no Larch
for Ada 95. LCLint is pretty useful for C programs, though I haven't used
it for large (> 100KLOC of C being large) programs. 

Anna was also an attempt, long dead by now. 

Maybe a big problem of Ada is that it is good enough at eliminating 
many problems that noone feels the effort of going further is worth it, 
unlike C, or "the squeaky wheel gets the grease". 

More likely is that Ada is not popular enough to justify the investment.
 
> > Sure, but different groups can develop independent modules in Ada, compile 
> > pieces independently, and link them together in the end and be sure that
> > the result contains no type violations (there could be other violations,
> > like range violations, which would correspond to violated assertions in 
> > Eiffel). This is not true of Eiffel.
> 
> It seems sort of silly to say, "Language X catches all *type* errors at
> compile time, but of course there are other errors that are caught only
> at run time", since the language definition defines what's a "type
> error" and what's an "other error".  Eg Ada catches variant record
> errors at run time.  One could reasonably call those "type errors", but
> the language definition says they're merely "constraint check failures".

Fair enough. However, if you accept Eiffel's own definition of what its 
types are (I'm not talking about assertion violations), then Eiffel is 
not statically type safe in any realistic sense, since there is not now
and has never been an Eiffel compiler which does full type checking of an
Eiffel program at compile time. Eiffel advocates will claim its not
important, and that serious users don't complain about this, but hey,
serious users of Smalltalk and CLOS don't complain that their lack of
static typing is a practical problem either, quite the opposite, they'll 
claim it leads to fewer bugs.

> I can easily define a language that catches *all* type errors at compile
> time, merely by defining "type error" to match what happens to be caught
> at compile time.

I still think constraint violations are more like assertion violations
than type errors, but you're entitled to your opinion of course, and can 
define things as you like.

-- Brian