From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,c52c30d32b866eae
X-Google-Attributes: gidfac41,public
X-Google-Thread: 1108a1,c52c30d32b866eae
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,2ea02452876a15e1
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Detecting type mismatch at compile time (was Re: Real OO)
Date: 1996/04/02
Message-ID: <EACHUS.96Apr2184154@spectre.mitre.org>#1/1
X-Deja-AN: 145504704
distribution: world
references: <4id031$cf9@dayuc.dayton.saic.com> <65O34ib-3RB@herold.franken.de>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object
Date: 1996-04-02T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <65lDeVZF3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

  > > Typically, a programmer comes upon this knowledge (that the dynamic type
  > > is exactly the specific type) because it is an obvious consequence of the
  > > algorithm, not because he has performed a sophsiticated data flow
  > > analysis by hand!  If an Ada programmer is mistaken, he will be told so
  > > by the failure of a tag check, at precisely the site of the attempt to
  > > assign or pass a value with one dynamic type to a variable declared to be
  > > of some different specific type.  No hunting necessary.

  > My (somewhat dogmatic) belief is that a program shouldn't fail
  > with a typing error at run-time. Types are a mechanism introduced
  > to allow the compiler to catch errors.  This is a pure opinion,
  > based on nothing more than the void in my head ;) - but I think I
  > could justify it, though with much handwaving.

   But the case being discussed above is exactly the one that can't be
detected until run-time.  For example, I can have a fruit class:

   type Fruit is abstract tagged null record;

-- and some member subclasses:

   type Apple is new Fruit with private;
   type Orange is new Fruit with private;

-- a type that designates any Fruit:

   type Fruit_Pointer is access Fruit'Class;

-- now I make an array of Fruit_Pointers:

   type Fruit_Arrangement is array (Integer range <>) of Fruit_Pointer;

-- and an instance of Fruit_Arrangement:

   FA: Fruit_Arrangement(1..10);

   Now at execution time I put some apples and some oranges in my
fruit arrangement, then do:

   S := FA(x) + FA(y);

   It is only at run-time that I know whether I am trying to add
apples and oranges.  In the corresponding case, where the type of the
operands can be determined at compile time, the error would be
diagnosed at compile time.  (Unless, of course, the programmer had
explicitly defined an operation to add apples to oranges. ;-)

   Maybe that smiley is misplaced.  There is a technique in Ada 95 for
cases where you do want to support heterogeneous operations.  The
fully general case often requires declaring several primitive
operations for each of the "visible" operations, but the others can be
private, and in some cases never need to be overridden.  In the much
more common case where the result type is always the same we could
define:

   function "+"(L,R: Fruit'Class) return Fruit_Arrangement;
   function "+"(L: Fruit_Arrangement; R: Fruit'Class) return
                  Fruit_Arrangement; 
   function "+"(L: Fruit'Class; R: Fruit_Arrangement) return
                  Fruit_Arrangement; 
   function "+"(L,R: Fruit_Arrangement) return Fruit_Arrangement;

   The body of the first plus is obviously:

   function "+"(L,R: Fruit'Class) return Fruit_Arrangement is
   begin
     return
       Fruit_Arrangement'(1 => new Fruit'Class(L), 2 => new Fruit'Class(R));
   end "+";
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...