Re: Naming of Tagged Types and Associated Packages

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

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