Re: Ichibah flames, and flames out over, Ada 9X

[wicklund@intellistor.com (Tom Wicklund)]

In <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

>I can feel a religious war coming on...

I don't want to start a religious war, but I think Mr. Taft's
experience with C++ is too limited.  On the other hand, I've never
done any real Ada programming so I apologize in advance for any errors
in my knowledge of Ada.

Both C++ and Ada have their strengths and weaknesses, I'm not fond of
either as a "favorite" langauge though I have some preference for C++
due primarily to better familiarity.

>Using classes for encapsulation works great in some circumstances,
>but breaks down in others.  If you are familiar with the
>way operators work in C++, and the subtleties having to do
>with implicit conversions on the "this" parameter versus the
>other parameter (the "that" parameter ;-), the appropriate
>use of "friends," etc., you begin to see the places where 
>class=module approach breaks down.

However, C++ doesn't use a class=module approach.  You're comment
applies more to a language like Eiffel.  C++ uses the class to control
information hiding, similar to (one function of) Ada's package.

>Consider a typical definition of a "complex" abstract data type in 
>Ada 83 (names of operations can be debated in e-mail):

>   generic
>       type Real is digits <>;
>   package Complex_Numbers is
>       type Complex is private;
>       function "+"(L, R : Complex) return Complex;
>       function "*"(L, R : Complex) return Complex;
>     . . .
>       function Cmplx(Re, Im : Real) return Complex;
>       function Re(C : Compex) return Real;
>       function Im(C : Compex) return Real;

>       type Imaginary is private;
>       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
>       function "*"(L : Real; R : Imaginary) return Imaginary;
>       function "*"(L : Imaginary; R : Real) return Imaginary;
>       function "+"(L : Real; R : Imaginary) return Complex;
>       function "+"(L : Imaginary; R : Real) return Complex;
>     . . .
>   private
>       type Complex is record
>         Re, Im : Real;
>       end record;

>       type Imaginary is new Real;
>   end Complex_Numbers;

>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.  There are differences, reflecting the
differences between Ada's and C++'s approaches to types and
differences in the approach to the implementation.

On the other hand, Ada packages are analagous to providing a "friend"
declaration between all types declared in the package.  If "friends
are so bad, then Complex and Imaginary should be in different packages
so they can't get at each other's internals (which is basically what a
C++ friend declaration does).

NOTE:  I've edited the following somewhat to remove inline function
implementations and several of the operations.

/* 
Copyright (C) 1988 Free Software Foundation
    written by Doug Lea (dl@rocky.oswego.edu)

This file is part of GNU CC.
*/

class Complex
{
protected:			// analagous to Ada's private part
  double           re;
  double           im;

public:
  inline double real() const;	// get real part of number
  inline double imag() const;	// get imaginary part of number

  // Create a complex number
  inline           Complex();
  inline           Complex(const Complex& y);
  inline           Complex(double r, double i=0);

  // assignment
  inline Complex&  operator =  (const Complex& y);

  // Basic operations (add to number, subtract from number, etc).
  inline Complex&  operator += (const Complex& y);
  inline Complex&  operator += (double y);
  inline Complex&  operator -= (const Complex& y);
  inline Complex&  operator -= (double y);
  inline Complex&  operator *= (const Complex& y);
  inline Complex&  operator *= (double y);

  Complex&         operator /= (const Complex& y); 
  Complex&         operator /= (double y); 
};

// Other operations on Complex.  No friend functions needed.

// Comparison operations.
int operator == (const Complex& x, const Complex& y);
int operator == (const Complex& x, double y);

int operator != (const Complex& x, const Complex& y);
int operator != (const Complex& x, double y);

Complex operator - (const Complex& x);	  // negation
Complex conj(const Complex& x);		  // conjugate

// Arithmetic:
Complex operator + (const Complex& x, const Complex& y);
Complex operator + (const Complex& x, double y);
Complex operator + (double x, const Complex& y);

Complex operator - (const Complex& x, const Complex& y);
Complex operator - (const Complex& x, double y);
Complex operator - (double x, const Complex& y);

// Similarly for *, /.

// More complicated operations:

Complex polar(double r, double t = 0.0);
Complex cos(const Complex& x);
Complex sin(const Complex& x);

// (removed abs, norm, arg, sinh, cosh, exp, log, pow (power), sqrt).


>  So much for language-enforced encapsulation.  And 
>here we have two types, Complex and Imaginary, that are interrelated,
>and are naturally defined in a single package.  One would
>have to resort to "friends" or perhaps nesting in C++.

I'm sure a C++ example could be created with classes Real, Imaginary,
and Complex.

There are also things which a C++ version could do and Ada can't.  For
instance, I don't think your Ada version as specified above allows
assignment between types, in particular, how do I assign an imaginary
value to a complex?

Complex := Imaginary;		   -- type violation.
Complex := Cmplx(Real, Imaginary); -- defined as Cmplx(Real, Real)
Complex := (0, Imaginary);	   -- private type.

I assume I have to get the package implementor to write a new function:

function Cmplx(re: Real; Im: Imaginary) return Complex;

Or alternately something like:

Complex := Cmplx(Re, Real(Im));	   -- use explicit conversion.
	   `			   -- can I do this to generics?

>The C++ solution might nevertheless be quite elegant, if structured
>properly according to reasonable coding guidelines, using the
>file=module model where appropriate.  But in this case, we see
>that Ada provides better direct encapsulation support than does
>a class-based language.

And one could write a very poorly structured Ada implementation which
violates package structures.  You may have some protection above
because the package is generic, I'm not familiar enough with Ada
generics.

I do agree that it's easier to create poorly packaged code in C++ than
in Ada.  From that standpoint Ada provides better encapsulation, but
it's by no means ideal.

There is also a problem discussed extensively in the Ada 9X materials
about how to handle mixing operations of types Matrix and Vector, so
Ada's encapsulation has it's problems also (this particular problem
isn't easy in either class based languages like Eiffel or in C++
either, though solutions can be done in any of these langauges).

>In any case, Ada 83 clearly chose the package-based approach, and
>we are not trying to change that for Ada 9X.  We felt that there
>was no need to force Ada programmers to adopt a different way of
>doing encapsulation just to get more support for dynamic binding 
>and type extension.

Regardless of the above, you're right to maintain Ada's encapsulation
philosophy.  I don't like Ada's approach as much as some others, but
there's nothing inherently wrong with it.

>We don't see the need to make Ada 9X a "me too" object-oriented
>language.  Instead, we want it to combine the best ideas of
>Ada 83 and OO languages, into something that advances the state
>of the art, not something that trails just behind always trying 
>to catch up.  We believe that this approach makes the most sense, 
>both technical, and marketing.  Your mileage may of course vary...

True, though I'm not sure Ada 9X is advancing the state of the art
past other languages (personal opinion).

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