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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: doylep@ecf.toronto.edu Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/08/11 Message-ID: <6qqd07$bko$1@nnrp1.dejanews.com> X-Deja-AN: 380169745 References: <6qfp80$p0u$1@nnrp1.dejanews.com> <6qnbms$ld7$1@nnrp1.dejanews.com> Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Aug 11 21:27:35 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.03 [en] (Win95; I) Date: 1998-08-11T00:00:00+00:00 List-Id: In article , Brian Rogoff wrote: > > On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote: > > > > 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. Well, it would be compiler-enforced case sensitivity *in addition* to different namespaces, but I think I get your point. > 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. Right. Fair enough. > 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 :-) True. I've seen those, and I probably find that about as distasteful as you do Eiffel's conventions. However, as you say, I'm sure I'd get used to it. > > 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. Well, I'm not sure that's the case. All that is needed is a check to make sure that an object conforms; after that, it can be assumed that it conforms, with all the implications that would have arisen if that could have been proven at compile time. Besides, because I dislike covariance, I don't use it, so I don't pay any penalty for it. > If you are willing to forego static checking, why use Eiffel or Ada at > all? Hey, let's be fair here; we're not really foregoing static checking. You can have it if you don't use covariance. And if you do use covariance, well then yes, you are foregoing static checking in those cases, so it's a tradeoff. However, even in such cases, Eiffel still offers the advantages of Design By Contract, plus its nice data type and algorithm libraries, which may be enough to make one want to use Eiffel even without 100% static type checking. > > 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. True. My real point is a much weaker one: simply that such compilers for Eiffel actually *exist* whereas (correct me if I'm wrong) they don't exist for Ada or any other language. In fact, the people who wrote the SmallEiffel compiler pioneered some techniques in system-wide optimizations, so I can say with some certainty that these things are not in any other compilers. Certainly the issue of what compilers *could* do is much more nebulous, and IMHO less relevant to language choices than what compilers *actually* do. (This is a double-edged sword, of course, since it cancels my point that Eiffel compilers *could* do system validity checks. :-) > 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? I believe there are no such compilers currently available. Don't get me wrong: I don't think the fact that Eiffel *requires* system validity checking is a good thing. Personally, I'd like to see covariance and feature hiding banished. > > 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... [points already covered above] Well, separately-compiled units are largely an illusion anyway, since any build process (that I'm aware of) requires at least one step which is system-wide. With C, for instance, the link phase is system-wide, and so is the dependency-checking phase (say, with makefiles). So separate compilation does not provide a different order of complexity versus system-wide approaches. At best it has a smaller multiplier; in the case of SmallEiffel vs. C, it has been my experience that even this is not the case. -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum