From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 11 Mar 93 15:13:25 GMT
From: noc.near.net!inmet!spock!stt@uunet.uu.net  (Tucker Taft)
Subject: Re: Ichibah flames, and flames out over, Ada 9X
Message-ID: <1993Mar11.151325.10801@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <1993Mar9.181231.27197@intellistor.com> 
  wicklund@intellistor.com (Tom Wicklund) writes:

>>How would you write this in a "class-based" language?
>>At least in C++, operators almost always have to be made "friends"
>>to work right.
>
>No they don't.  I suggest you look at the GNU g++ library
>implementation of complex, which I summarize below.  Note that there
>are NO friend functions.  

Thanks for pointing this out.  What I should have said
was that operators must generally *not* be member functions
if they are going to work right in conjunction with
implicit conversions.  As you illustrate, if the functionaliy
of a non-member-function operator can be expressed in terms
of some member function (operator or otherwise), then there
is no need to make the non-member-function operator a "friend."

Your example, however, illustrates the point I was *trying* (albeit
ineffectively ;-) to make, that the "encapsulation" provided
by a C++ class construct is not always complete, since one must revert
to non-member-function declarations (for example for many binary
operators) to get the desired functionality.  This is neither
good nor bad as far as I am concerned.  It just shows that a
"religious" belief that "class-based" languages (in as much
as C++ is one) do a better job of encapsulating all of the 
interesting operations "inside" the class, doesn't always 
turn out to be true.  However, by using files as modules, one
can get the logical grouping you desire in C++.

In Ada, the package provides all encapsulation, both for
the equivalent of member functions ("primitive subprograms" in
Ada 9X, "derivable subprograms" in Ada 83) and for any
associated types, operators, exceptions, generics, etc.
Either way works, but having *both* a class-based encapsulation
and a package-based encapsulation in a single language would
almost certainly result in undesirable complexity and confusion.

As far as the great "class" vs. "tagged" debate, Ada 9X does
have classes, and in fact the word "Class" appears quite prominently
in any Ada 9X example that uses polymorphism.  It just doesn't
happen to appear in the declaration of a tagged type.
Instead it appears in the declaration of polymorphic operations
and access types.  The concept of "class" is also behind the scenes 
any time you define a generic with a formal type 
like "type I is range <>;" since any type in the integer "class"
matches such a declaration (this is an example of compile-time
polymorphism).

As far as marketing to the masses, the big term these days 
is "object technology" not "class-based languages."
Given that, we should presume that Modula-3, since it uses
the term "object" in its syntax for OOP-related types, should
soon take over the world!  

One last note, before I retire from this debate, for the history buffs
who like to quote the computer science greats...

  One of the earlier places where the term "tag" appears in scholarly
  circles is in the classic book "Structured Programming" by
  O.-J. Dahl, E. W. Dijkstra, and C. A. R. Hoare.
  In Hoare's chapter entitled "Notes on Data Structuring,"
  in the section on "The Discriminated Union" he begins
  his subsection on "Manipulation" as follows:

     Any value of a discriminated union carries with it a "tag"
     field indicating which of the particular constituent types it
     originated from; on assignment this is copied, and on a test
     of equality, the tag fields must be the same if the values
     are to be equal.

  Hoare and Niklaus Wirth collaborated somewhat on the development
  of this concept, and "tag" was the term Wirth adopted in his
  description of Pascal (e.g. in the Pascal User Manual and Report).

  The term "tag" is also used in more recent "scholarly" contexts, 
  particularly in a paper on "Dynamic Typing in a Statically Typed 
  Language" by Abadi, Cardelli, Pierce, and Plotkin (TOPLAS 4/91).

Probably the major objection to the term "tagged" is that
it *sounds* too low-level and implementation oriented.  Of course,
some might find that comforting in a systems-programming language.
But even for those who prefer abstractness in a language, the
term "tagged" really just means "self-identifying."
Each "tagged" object in Ada 9X identifies its own underlying type.  
This is the key to run-time polymorphism, and is the critical step from
an abstraction-oriented language like Ada 83, to an "object"-oriented
language like Ada 9X.  In Ada 83, a given abstraction interface
has exactly one implementation.  In Ada 9X, as in other OOP languages,
a given interface may have many implementations, typically organized
into some kind of hierarchy.  The objects carry around an identifying
(abstract ;-) tag that allows them all to be manipulated through
a common interface, but still nevertheless to be treated specially
according to their self-identifying tag when appropriate, through
the "magic" of run-time dispatching.  Ada 83 already had abstract
data types (unlike C); they were called "private types."  In Ada 9X,
abstract data types are still called private types.  However, if
you want to use them with run-time polymorphism, then they have
to be "tagged" private types.  But they are still "private" types, 
and in many cases that is more fundamental than the fact
that they are "tagged."

So that's the technical/computer-science justification for the term.
As far as marketing, we do use the term "class" heavily in Ada 9X,
and we use it in a way that meshes nicely with its use in other
OO languages.  However, we made a judgement call that to use
it in the *syntax* of tagged types, and to call such types
"class types" would result in more problems (marketing and technical)
than it solved.

This judgement call was based on technical merit, on
marketing considerations, on usability, etc.  Of course, others
might reach a different conclusion (of course, others *have* reached
a different conclusion ;-).  Such is the way with language design.
You have to make some tough, but in many ways, "arbitrary" choices,
using the clearest "crystal ball" you can devise, and with an
eye toward the overall consistency and aesthetics of the language --
it is unwise to try to make one "corner" of the language "beautiful"
at the expense of overall consistency and usability.

In any case, it is quite unlikely that you will please everyone with
every design choice.  It is quite likely that there will be some vocal,
heartfelt, and well justified arguments on the opposite side of
almost every decision.  This particular choice seems to be
one of the "canonical" examples of that phenomenon.

But at some point, you make a decision and move on.  In this area,
we have done that, and only posterity will be able to confirm
whose "crystal ball" was clearer.  The only thing worth reiterating,
is that even if you don't agree with our decision, please believe
that we have the same technical, usability, and marketing concerns
as everyone who hopes that Ada 9X will be a widely-used, highly
productive programming language for developing and maintaining
the complex software systems of the 90's and beyond.

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138