comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: MI for Ada
Date: 1999/02/16
Date: 1999-02-16T00:00:00+00:00	[thread overview]
Message-ID: <EACHUS.99Feb16110742@spectre.mitre.org> (raw)
In-Reply-To: 7a7aav$mse$2@plug.news.pipex.net

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




  parent reply	other threads:[~1999-02-16  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-11  0:00 MI for Ada Brian Rogoff
1999-02-11  0:00 ` Tucker Taft
1999-02-12  0:00   ` Robert I. Eachus
1999-02-12  0:00     ` Brian Rogoff
1999-02-13  0:00     ` Alexy V Khrabrov
1999-02-14  0:00       ` Nick Roberts
1999-02-15  0:00         ` robert_dewar
1999-02-18  0:00           ` Nick Roberts
1999-02-16  0:00         ` Robert I. Eachus [this message]
1999-02-16  0:00           ` robert_dewar
1999-02-16  0:00             ` Robert I. Eachus
1999-02-17  0:00           ` Brian Rogoff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox