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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,5f5a48f21d7f7525
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder.news-service.com!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 24 Jun 2010 09:25:21 +0200
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Inferring array index type from array object
References: 
 <6b20ed09-efc1-4df7-90f9-5e141482e8d0@d37g2000yqm.googlegroups.com>
	<1305oqccr1h2t$.x33x4oxwd84d$.dlg@40tude.net>
	<hvsikv$3a7$1@news.eternal-september.org>
	<4c21fd04$0$6769$9b4e6d93@newsspool3.arcor-online.net>
	<hvt034$ot3$1@news.eternal-september.org> <m2eifxzhuj.fsf@pushface.org>
In-Reply-To: <m2eifxzhuj.fsf@pushface.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4c230861$0$6977$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 24 Jun 2010 09:25:21 CEST
NNTP-Posting-Host: a3a298f4.newsspool4.arcor-online.net
X-Trace: 
 DXC=:KC3_6Tc:7F^B]`=U:WelB4IUK<Cl32<A4Fo<]lROoRA8kF<OcfhCOKVP?0TCfN=kEPCY\c7>ejVH4^BaiI\\M\JGZn7fWLeJ`E
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:12882
Date: 2010-06-24T09:25:21+02:00
List-Id: <comp.lang.ada>

On 6/23/10 9:09 PM, Simon Wright wrote:
> "J-P. Rosen"<rosen@adalog.fr>  writes:
>
>> outside the instantiation, you are supposed to know how it was
>> instantiated, therefore you have access to the actuals. Why would you
>> need to reexport the formals?
>
> Formal types, yes, not so sure about formal objects. Consider eg a
> generic signature package ..
>
>     generic
>
>        type Severity_Code is (<>);
>        --  Messages are logged with this indication of severity.
>
>        Error : Severity_Code;
>        --  This value is used for error messages.
>
>        Informational : Severity_Code;
>        --  This value is used for informational messages.
>
>        with procedure Log (Severity : Severity_Code; Message : String);
>
>     package Logging_Signature is
>
>        --  Make the actual instantiation parameters visible.
>        package Exported is
>           Error : Severity_Code renames Logging_Signature.Error;
>           Informational : Severity_Code renames Logging_Signature.Informational;
>           procedure Log (Severity : Severity_Code; Message : String)
>             renames Logging_Signature.Log;
>        end Exported;
>

Similarly, without reference to names outside the generic,
at least as a temptation: If some container has a "regular
interface", one can think of an algorithm in terms of names
that from the container only.

with Some_Container;
generic
   with package Collection is new Some_Container (<>);
procedure Copy (input: Collection.T; output: in out Collection.T);
   -- copies objects of type Collection.E,
   -- from and to objects of type Collection.T,
   -- pointed to by objects of type Collection.Cursor.

generic
    type Element_Type is private;
package Some_Container is
    subtype E is Element_Type;
    type ... Set, List, Map, ... is private;
    subtype T is ... Set, List, Map, ...;
    ...
    type Cursor is private;
    ...
private
    ...
end Some_Container;

OTOH, it might be OK to make the Copy procedure from above
a child of Some_Container.  Since everything needed by Copy
is then "exported" by Some_Container to children, this might
do.

(It is not a solution to Simon's case, though, I guess.)