MI for Ada

MI for Ada

[Brian Rogoff]

Hi,
	I've been thinking lately about how to go about adding Java style 
interfaces or GNU C++ signatures to Ada. While syntax is probably the
easiest part of such an addition, I thought I'd pose the topic here to
others who've undoubtedly thought longer on this topic than I have. Does 
anyone have strong opinions on this topic (syntax), like whether new
keywords should be added or not? 

	I find the restricted MI of Java and GNU C++ signatures appealing.
Ada already has forms of MI of implementation, so such an addition would 
make Ada OOP significantly nicer, without making it much more complex. 
Comments?

-- Brian

Re: MI for Ada

[Tucker Taft]

Brian Rogoff wrote:
> 
> Hi,
>         I've been thinking lately about how to go about adding Java style
> interfaces or GNU C++ signatures to Ada. While syntax is probably the
> easiest part of such an addition, I thought I'd pose the topic here to
> others who've undoubtedly thought longer on this topic than I have. Does
> anyone have strong opinions on this topic (syntax), like whether new
> keywords should be added or not?

It is probably too soon to tell.  I suggest you design the
semantics of the feature.  It may be that there are keywords
that work already.  Norm Cohen is famous for coming up with
great combinations of existing keywords, if you need help.
But don't be afraid of adding new keywords if necessary.

>         I find the restricted MI of Java and GNU C++ signatures appealing.
> Ada already has forms of MI of implementation, so such an addition would
> make Ada OOP significantly nicer, without making it much more complex.
> Comments?

I agree that multiple inheritance of *interface* only is a
more pleasing approach than the full-blown MI of implementation
(in two different ways!) found in C++.

Future revisions to Ada will almost certainly be based on
experimental results, rather than the pure thought experiments
we were forced to use last time.  So by all means, experiment!

> 
> -- Brian

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: MI for Ada

[Robert I. Eachus]

In article <36C365F8.50E84F94@averstar.com> Tucker Taft <stt@averstar.com> writes:

  > It is probably too soon to tell.  I suggest you design the
  > semantics of the feature.  It may be that there are keywords that
  > work already.

  package Foo is new Bar(X,Y,Z) with body ... end Foo;

  Of course, given the opportunity to add a new body to a subprogram
or package, it would also be useful to be able to define a template
without an implementation:

  generic
    X,Y,Z: Integer;
  abstract package Bar is ... end Bar;

  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
work, but the next step to allow a new generic to be derived from an
existing and extend the interface is MUCH more work:

   generic
     type W is private;
   package Foo is new generic Bar with
     function Foobar return W;
   end Foo;
--

					Robert I. Eachus

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

Re: MI for Ada

[Brian Rogoff]

On 12 Feb 1999, Robert I. Eachus wrote:
> Tucker Taft <stt@averstar.com> writes:
> 
>   > It is probably too soon to tell.  I suggest you design the
>   > semantics of the feature.  It may be that there are keywords that
>   > work already.
> 
>   package Foo is new Bar(X,Y,Z) with body ... end Foo;

Hmmm, you seem to be designing an "MI of package" facility. I was thinking
of something more like Java interfaces, which would allow types to conform
to multiple interfaces based on the set of primitive functions they support. 
I'd like to have access to interface variables too, so that I could
define subprograms which are defined in terms of such variables, and
would work on any access types which conform to the stated interface. If
you know about GNU C++ signatures, thats really what I have in mind. No 
fundamental extensions to Ada's package system, just a way to specify 
signatures/interfaces, access to signature/interface, probably a "sigof" 
construct to get a signature from a type, and of course all the necessary
changes to have generic formal signature parameters.

There are probably some opportunities for streamlining Ada's package 
composition facilities by adding some kind of package inheritance; for
example I'd love to be able to define generic signature packages
for the different categories of iterator incrementally. Is that the sort
of problem your proposal is meant to address?

-- Brian

Re: MI for Ada

[Alexy V Khrabrov]

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


It's just amazing how a strict monastery whose charter is LRM can get soft
during Clinton's administration!  :-))  That's what governmental affiliation
does even to the creme-de-la-creme sect of the Ada gurus!  No wonder the
Standard and ACVC were a part of Reaganomics...  Nah, nothing's clear in
these times...  OOPs/ShmOOPs...  :-)))  MS Projects taking over people's
lives, malicious MS Objects COMmunicating with Ketzalkoatl, their master and
protector...  Brrrr...  Still, Clinton/Java is better than Reagan/Ada!  Sad
but true, you may not be a programmer, but have to be a citizen.

Cheers,
Alexy

Re: MI for Ada

[Nick Roberts]

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.
-------------------------------------------

Re: MI for Ada

[robert_dewar]

In article <7a7aav$mse$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> 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.

It is equally valid to have the RM mode activated by a
flag, there is no sense which requires the "default" mode
(whatever that means) to be the RM mode.
>
> 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.


Hmm! Nick, you have a long way to go in analyzing difficult
RM issues. No particular difficulty??? This is in fact a
VERY difficult proposal to get right, and almost certainly
it will run aground on any number of rocks on the way.

Have you read the AI's. I assume so if you are even vaguely
serious about implementing an Ada 95 compiler. If not, you
should, it would give you an interesting insight into the
delicate semantic issues of the language. Actually reading
the AARM is also a good way to get a feeling for this.

Multiple inheritance is a well known landmine in
programming language semantic definition land!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: MI for Ada

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7a86q2$kec$1@nnrp1.dejanews.com>...
[...]
|Hmm! Nick, you have a long way to go in analyzing difficult
|RM issues. No particular difficulty??? This is in fact a
|VERY difficult proposal to get right, and almost certainly
|it will run aground on any number of rocks on the way.
|
|Multiple inheritance is a well known landmine in
|programming language semantic definition land!

Noted.

|Have you read the AI's. I assume so if you are even vaguely
|serious about implementing an Ada 95 compiler. If not, you
|should, it would give you an interesting insight into the
|delicate semantic issues of the language. Actually reading
|the AARM is also a good way to get a feeling for this.


I'm in the process of reading the AI95s and the AARM. And yes, both are most
illuminating. Entertaining too, sometimes. The comment on the end of the AI
on the 'List' pragma - something like "this must be the most pointless AI
imaginable" - made me laugh out loud. I was amazed at how another
(admittedly unimportant) AI, about time zones, seems to be just dropped
unresolved. But that'll keep for another thread.

And yes, I am serious about it. I don't have any great illusion about the
enormity of the task - I suppose I feel a bit like Edmund Hillary or Tensing
Norgay standing at the foot of Mt Everest/Chomolungma - but I intend to
conquer!

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

Nothing Venture, Nothing Win
-------------------------------------

Re: MI for Ada

[Robert I. Eachus]

In article <7a7aav$mse$2@plug.news.pipex.net> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

 > 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.

   You have to understand that there are two roles involved, and most
good language lawyers are also language designers, closet or
otherwise.  And as you are aware in Ada 83 the rule was "no
unauthorized extensions."  In Ada 95, there must be a standard
conforming mode.  One of the hopes for the GNAT project is that it
will make trying out potential extensions much easier.

   The extension of generics that I suggested is mostly syntactic
sugar, but I think it is the kind of extension that "Makes Ada more
Ada-like."  It makes such tailorable generic packages easier for the
reader to understand.  Instead of a generic with dozens or hundreds of
formal parameters, you make it clear you are declaring the interface,
and the instantiation must provide a body.  A perfect example of how
to use this is sorting.  You could have a package with a (generic
formal subprogram) parameter which indicates the sort algorithm
desired.  This is possible now, I was just suggesting a much cleaner
syntax.

  > 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).

    Actually you don't need the rule about overlapping, you can either
have a rule about precedence order, or better, require that any such
subprogram be explicitly overridden, with the possible exception of "=".
That seems much more like the Ada way.

  > Something for Ada 200X, perhaps?

    There is a major difference between making multiple inheritance
workable, and making it useful.  I'm convinced that for Ada, the first
is possible, but with the mix-in idiom that is very usable now, I
don't see what "true" multiple inheritance gains other than to confuse
the definition of parent type.




--

					Robert I. Eachus

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

Re: MI for Ada

[robert_dewar]

In article <EACHUS.99Feb16110742@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> And as you are aware in Ada 83 the rule was "no
> unauthorized extensions."  In Ada 95, there must be a
> standard conforming mode.

This is highly misleading. There has been no change here
between Ada 83 and Ada 95. It was always understood and
never questioned that Ada compilers could have flags that
caused them to operate in some non-standard mode, and this
was true from the start for Ada 83. For example, nearly
all compilers had a flag for suppressing runtime checks.

The ARG discussed this a few times, and always unanimously
agreed that even the most outrageous switches were
perfectly fine as long as there was a standard conforming
mode, and the ACVC procedures have always required that the
VSR document the switches used to achieve this mode.

So Robert Eachus' implication that there has been some
shift in the Ada 95 design here is, as they would say
in the British parliament, a "terminological inexactitude".


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: MI for Ada

[Robert I. Eachus]

In article <7acbdd$316$1@nnrp1.dejanews.com> robert_dewar@my-dejanews.com writes:

  > So Robert Eachus' implication that there has been some
  > shift in the Ada 95 design here is, as they would say
  > in the British parliament, a "terminological inexactitude".

   Sorry, I always thought that the "no unauthorized extensions" was a
clever in joke, but I guess it is a little too in for this forum.  It
looks like a draconian rule, but in practice it is a license with very
little limitation except good documentation.  For example, it has
always been perfectly legitimate in terms of validation to have a
compiler which under the influence of some mysterious switch compiled
FORTRAN or C instead of Ada.  In fact, some compilers that do just
that based on the name of the source file presented to them. ;-)

   As Robert points out, there is no real difference between the Ada
83 and Ada 95 validation rules in terms of conformance, even though
the RM wording is a little different:

   Ada 83 RM 1.1.2(6-7):

   "(e) Contains no variations except where the standard permits.

   "(f) Specifies all such permitted variations in the manner
prescribed by the standard."

   Ada 95 RM 1.1.3(6-7):

   "- Contain no variations except those explicity permitted by this
International Standard, or those that are impossible or impractical to
avoid given the implementation's execution environment;

   "- Specify all such variations in the manner prescribed by this
International Standard."

   In Ada 83, these variations were specified in Appendix F, and in
Ada 95 they are found in Annex M.  In either version, if you care
about conformance to the standard you will have a copy of this close
at hand, along with the Validation Summary Report.

   
--

					Robert I. Eachus

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

Re: MI for Ada

[Brian Rogoff]

On 16 Feb 1999, Robert I. Eachus wrote:
>    The extension of generics that I suggested is mostly syntactic
> sugar, but I think it is the kind of extension that "Makes Ada more
> Ada-like."  It makes such tailorable generic packages easier for the
> reader to understand.  Instead of a generic with dozens or hundreds of
> formal parameters, you make it clear you are declaring the interface,
> and the instantiation must provide a body.  A perfect example of how
> to use this is sorting.  You could have a package with a (generic
> formal subprogram) parameter which indicates the sort algorithm
> desired.  This is possible now, I was just suggesting a much cleaner
> syntax.

I'd be interested in seeing some more examples of your proposal in use, 
since I don't think I understand its semantics yet. 

>   > 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).
> 
>     Actually you don't need the rule about overlapping, you can either
> have a rule about precedence order, or better, require that any such
> subprogram be explicitly overridden, with the possible exception of "=".
> That seems much more like the Ada way.
> 
>   > Something for Ada 200X, perhaps?
> 
>     There is a major difference between making multiple inheritance
> workable, and making it useful.  I'm convinced that for Ada, the first
> is possible, but with the mix-in idiom that is very usable now, I
> don't see what "true" multiple inheritance gains other than to confuse
> the definition of parent type.

How about "false" multiple inheritance, a-la Java, Objective-C, GNU C++ 
with signatures, etc? Following the GNU C++ idea, we create some new
entities, signatures and signature access types. These signatures
correspond directly to Java interfaces, and the signature access types are
there so that you can declare variables which conform to a signature. 

I think the general idea is fairly simple, and provides something that 
Ada doesn't handle well right now with its mix-in idioms. Unfortunately, 
I suspect the integration into Ada requires someone with a bigger brain
than mine, or at least one that lives and breathes RM and AARM :-).

-- Brian