From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/08/13 Message-ID: #1/1 X-Deja-AN: 380986073 References: <6qfp80$p0u$1@nnrp1.dejanews.com><6qnbms$ld7$1@nnrp1.dejanews.com><6qqd07$bko$1@nnrp1.dejanews.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 903068795 1136 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-08-13T00:00:00+00:00 List-Id: On Thu, 13 Aug 1998, Robert A Duff wrote: > Brian Rogoff 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