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/10 Message-ID: #1/1 X-Deja-AN: 379879923 References: <6qfp80$p0u$1@nnrp1.dejanews.com> <6qnbms$ld7$1@nnrp1.dejanews.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 902793607 14193 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-08-10T00:00:00+00:00 List-Id: On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote: > Brian Rogoff wrote: > > Call the steering wheel Steering_Wheel, and call the type something like > > Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names > > and variable names to be lexically distinguished, so the EuLisp/Dylan > > convention, which would be to name it something like , > > would be my choice if I could do it all myself, but I don't think the > > _Type convention is bad at all, and its used widely in my Ada reference > > of choice (Ada as a Second Language). > > The Eiffel convention is to use uppercase for class names and lowercase for > feature names. Does this fit the bill? Some compilers won't even accept > source code that does not follow this convention, so other programmers not > conforming is not an issue. Well, its definitely lexically distinguishable in a case sensitive language, but as I said earlier, I find it aesthetically unappealling to rely on case alone for the distinction. Even in C and Java, I use more than case to distinguish. Personally, I don't mind a little redundancy, and I find all of this talk of "noise" in the type name really funny, as though its somehow really difficult for the reader to deal with this _Type business. However, as I also said, if I were to use Eiffel or a similar language long enough, I'm pretty sure I'd get used to it, even if I don't like that convention now. > > If you want to talk about having to create contrived names, be careful, > > Eiffel doesn't have overloading, which is far worse IMO. Apparently the > > Sather designers agreed, when they decided to "fix" Eiffel, they added > > overloading. Other languages, like OCaml, do away with most of the need > > to name types altogether, so the antiredundantists should consider such > > languages before disparaging the Ada way in deference to Eiffel way. > > Perhaps, but preventing redundancy is still a good thing, so the fact that a > language is redundant in one sense doesn't change the fact that eliminating > redundancy in another sense is a Good Thing. You're absolutely correct here. However, I don't think Ada will change (in this regard) anytime to soon, nor will Eiffel adopt overloading, so I think if I have a choice, I find overloading to be a more useful feature in eliminating redundancy in name choice. If you really want to look at eliminating redundancy, look at languages which do are indentation sensitive (Python, Haskell, ...) and eliminate all of those noisy begin...end pairs. 1/2 :-) ... snip ... > > Fair enough. I don't like covariance either. But as for whole-program > analysis... > > First, this is not necessary if you're satisfied with some type checking being > done at runtime. And significantly less optimization too, at that point. > So the accurate assessment would be that whole-program > analysis is required for static type safety, rather than to make Eiffel usable > at all. If you are willing to forego static checking, why use Eiffel or Ada at all? > Second, SmallEiffel is a compiler which has dived whole-heartedly into a > system-wide approach, and as such is able to make *massive* optimisations > which produce excellent executables. Since the compiler is compiled by > itself, it makes use of these optimisations to provide system-wide > compilation which is of comparable speed to module-wise compilation systems. Nothing stops you from getting the best of both worlds in Ada, since nothing in Ada precludes you from doing whole program analysis, that is assuming you have the whole program to analyze. In Eiffel, you have to do whole program analysis to get type safety, and I don't believe that any Eiffel compiler even does the entire analysis (system level validity checking, or now polymorphic catcall checking?), so I just can't see this as being an Eiffel advantage. Just for my education, do any current Eiffel compilers actually do all of the analysis? > In fact, because SmallEiffel compiles to C, it is possible to compare the > system-wide approach to the module-wise approach directly, and the Eiffel-to-C > phase of compilation is invariably faster than the C-to-native phase, often by > an order of magnitude, despite the fact that the C-to-native phase only > compiles the portions that have changed. It is dangerous to draw too many > conclusions from this, but one thing that is clear is that the system-wide > approach does not have a significant impact on compile time. Sorry, I don't believe it. A language with separately compiled modules will always have an advantage here; as I said above, you could apply the same technology to Ada or a similar language, and you'd be guaranteed type safety too, whereas with Eiffel you really have to check the whole program or defer some checks until run time. Seems to defeat the purpose of static checking at that point. -- Brian