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.2 required=5.0 tests=BAYES_00,FROM_WORDY,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f4f6a5b783e1150c
X-Google-Attributes: gid103376,public
From: "Nick Roberts" <Nick.Roberts@dial.pipex.com>
Subject: Re: MI for Ada
Date: 1999/02/14
Message-ID: <7a7aav$mse$2@plug.news.pipex.net>#1/1
X-Deja-AN: 444355700
References: 
 <Pine.BSF.4.05.9902111400440.7727-100000@shell5.ba.best.com><36C365F8.50E84F94@averstar.com>
 <EACHUS.99Feb12142926@spectre.mitre.org>
 <7a2j8q$meo@bgtnsc01.worldnet.att.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: UUNET WorldCom server (post doesn't reflect views of UUNET
 WorldCom)
Newsgroups: comp.lang.ada
Date: 1999-02-14T00:00:00+00:00
List-Id: <comp.lang.ada>

Alexy V Khrabrov wrote in message <7a2j8q$meo@bgtnsc01.worldnet.att.net>...
|
|Robert I. Eachus wrote [an unspeakable blasphemy in 1983] in his message:
|
|>  It would be a very useful extension to the language.  Any one want
|>to work out the details of the semantics, then add it to gnat as a
|>language extension?  I suspect that taking it that far is not too much


A blasphemy in 1983 perhaps, but not such a blasphemy now. Provided the
extended syntax is rejected when the compiler is in 'standard mode', and
accepted in some special mode (probably activated by a compiler flag), the
sacred snake remains in his lair.

Actually, it occurs to me that there is no particular difficulty in
providing multiple inheritance from several publicly null-record tagged
types at the same time. The new type would have to implement all the
promised subprograms of both/all its parents, and (probably) it would have
to be illegal for any such subprograms to 'overlap' (have same name &
profile). Class membership tests for such types could be implemented by
chaining the descriptors in series (the user would never know).

For example:

   package Pa is
      type Ta is abstract tagged null record;
      function F1 (X: in Ta) return Ta is abstract;
   end Pa;

   package Pb is
      type Tb is abstract tagged null record;
      function F2 (X: in Tb) return Tb is abstract;
   end Pa;

   package Pc is
      type Tc is new Ta, Tb with private;
      function F1 (X: in Tc) return Tc;
      function F2 (X: in Tc) return Tc;
   private
      ...
   end Pc;

The last type declaration would really just be a convenient way of writing

       type anon is new Ta with null record;
       function F2 (X: in anon) return anon is abstract;
       type Tc is new anon with private;

or equally

       type anon is new Tb with null record;
       function F1 (X: in anon) return anon is abstract;
       type Tc is new anon with private;

but I think it's clear that this could be a facility that would be very
convenient at times.

There would be a difference, in that both "X in Ta'Class" and "X in
Tb'Class" would be true, if X were of type Tc. This functionality could be
implemented by making a copy of the descriptor (the vector table) for Ta,
and parent-linking this vector table to Tb, and then Tc's descriptor to this
special copy of Ta's. You would have to store a tag value in each descriptor
(rather than using the address of the descriptor as the tag).

I suspect this is stuff that the Ada 95 design people went over (a lot).

Something for Ada 200X, perhaps?

-------------------------------------------
Nick Roberts

The meek shall inherit the Earth. And then
pay the capital transfer tax on it in full.
-------------------------------------------