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: Robert A Duff Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/08/13 Message-ID: #1/1 X-Deja-AN: 380899304 Sender: bobduff@world.std.com (Robert A Duff) References: <6qfp80$p0u$1@nnrp1.dejanews.com> <6qnbms$ld7$1@nnrp1.dejanews.com> <6qqd07$bko$1@nnrp1.dejanews.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1998-08-13T00:00:00+00:00 List-Id: 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. If that type info weren't automatically kept around, the programmer would have to keep that same information explicitly. Note that the type info isn't being used here to perform run-time type checking; in both languages, there's guaranteed to be an appropriate Mumble to call. > 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. > 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". 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. Some folks would consider "divide by zero" to be a type error. But most languages catch it at run time. I could force it to be caught at compile time, but it might not improve the programming language. - Bob -- Change robert to bob to get my real email address. Sorry.