Re: Naming of Tagged Types and Associated Packages

[doylep@ecf.toronto.edu]

In article <Pine.BSF.3.96.980810163352.29141A-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> 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