Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff <bpr@shell5.ba.best.com>]

I think we've strayed far from the naming discussion, so maybe we should 
continue this on comp.lang.misc, since some other languages besides Ada 
are being discussed, or privately via e-mail. I have no interest in
expanding the newsgroups line, and I'm beginning to think that
crossposting in general is a questionable practice. 

On Tue, 11 Aug 1998 doylep@ecf.toronto.edu wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > 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.

Indeed, you may even find that here are certain advantages to this choice. 
I found it rather unnerving at first myself. I don't have a lot of
experience with these languages, so I can't say how I'll feel in a few
years time. My Python programs have tended to be small, and Haskell is
more of an academic curiosity to me than a language that I'd use for real
programming. Maybe one day...

> > > 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.

I think if you keep type information around at run time, you've sacrificed 
some optimization, right?

> Besides, because I dislike covariance, I don't use it, so I don't pay any
> penalty for it.

But you also can't use anyone else's Eiffel program if they don't share 
your dislike, else you'll pay the penalty. 

It almost sounds like you were a Sather user, or at least that you'd have
really liked Sather.

> > 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, 

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.

But I accept that my statement is unfair, and you may like Eiffel at many
levels.

> 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.

Eiffel lacks the ability to do system level programming (low level
mucking) so I'm not sure that its data types are really more powerful than
what you get in Ada. 

> > 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.

The Scheme compiler Stalin, at 

	http://www.neci.nj.nec.com/homepages/qobi/software.html

does extensive system wide optimizations, and compiles Scheme down to some 
mighty fast C. Whether other compilers do exactly what SmallEiffel does is 
probably not relevant, Eiffel needs certain optimizations to be fast,
Scheme needs others, and Ada probably others still.

I don't know of any Ada compilers which do whole program optimization.

> Certainly the issue of what compilers *could* do is much more nebulous, and
> IMHO less relevant to language choices than what compilers *actually* do. 

Very true, and also relevant to my comment about DBC as an external tool
for Ada; since it hasn't been done I shouldn't claim that the possibility
of doing negates the Eiffel advantage here, so I don't.

> 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.

Have you looked at Sather? It looks like what you want, though it seems 
moribund now.

> > 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).

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.

-- Brian