From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 8 Oct 92 19:54:52 GMT
From: dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!hobbes.ph
ysics.uiowa.edu!news.uiowa.edu!news@ucbvax.Berkeley.EDU  (Douglas W. Jones,201H
 MLH,3193350740,3193382879)
Subject: Re: Generic Instantiation as Subprogram Body?
Message-ID: <1992Oct8.195452.10224@news.uiowa.edu>
List-Id: <comp.lang.ada>

>>From article <dnsurber.718567247@node_26400>,
by dnsurber@lescsse.jsc.nasa.gov (Douglas N. Surber):
> 
>     generic
> 	type T is range <>;
>     package P is
> 	type U is private;
> 	function "<" (l,r : U) return boolean;
>     private
> 	type U is new T;    -- or whatever
>     end P;
> 
>     package body P is
> 
> 	-- the following doesn't work. declared function name hides the
> 	-- generic actual.
> 	function "<" is new ...
> 
>     end P;

I've been bothered by this too.  The only solution I've found that works
is to write some long-winded boilerplate in the package body; specifically,
You have to write it like this:

      package body P is

	function "<" (l,r : U) is
	begin
	    return T'(l) < T'(r)
	end "<";

      end P;

That is, you declare a stubby procedure that explicitly coerces its two
parameters of type U to the base type T, then applies the < operation you
want for that base type.

I run into this most often when I use a generic list type in the
a package that exports list operations.  I'd like to just export the
generic instantiations of the list operations on a specific type, but
I can't do it directly; instead, I have to package the exported operations
with annoying little functions like the one shown above.

Of course, this function can be "inlined", so it should cost nothing at
run-time, but these things make for pages of unnecessary source code!

					Doug Jones
					jones@cs.uiowa.edu