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: 103376,f4f6a5b783e1150c
X-Google-Attributes: gid103376,public
From: Brian Rogoff <bpr@shell5.ba.best.com>
Subject: Re: MI for Ada
Date: 1999/02/12
Message-ID: <Pine.BSF.4.05.9902121151240.28868-100000@shell5.ba.best.com>#1/1
X-Deja-AN: 443732082
References: <Pine.BSF.4.05.9902111400440.7727-100000@shell5.ba.best.com>
 <36C365F8.50E84F94@averstar.com> <EACHUS.99Feb12142926@spectre.mitre.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: nntp1.ba.best.com 918851020 16682 bpr@206.184.139.136
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-02-12T00:00:00+00:00
List-Id: <comp.lang.ada>

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