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,c908d18110a09ea4,start
X-Google-Attributes: gid103376,public
From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)
Subject: Supplying a parameter for "digits"
Date: 1996/08/14
Message-ID: <4url7g$j6f@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 174913419
organization: Comp Sci, RMIT, Melbourne, Australia
nntp-posting-user: ok
newsgroups: comp.lang.ada
Date: 1996-08-14T00:00:00+00:00
List-Id: <comp.lang.ada>


I want to write a generic package that takes two floating point types.
Within that package, I want to have a floating point type which is at
as precise as the more precise of the two parameter types.

If I could, this is what I would write:

    generic

	type Coord is digits <>;
	type Value is digits <>;

    package Example is

	type Product is digits Max(Coord'Digits, Value'Digits);

I _don't_ want to specify System.Max_Digits, or Long_Float, or anything
like that; if I was happy with that I could stick with Fortran or C.

In Ada 83 I couldn't say this because there was no Max.
In Ada 95, Digits is of type universal_integer, but 'Max must be tied
to some named type, so the obvious thing is to try

	type Product is
	    digits Integer'Max(Coord'Digits, Value'Digits);

Unfortunately, GNAT says 
	"non-static expression used for digits value".

Quoting the AARM (5.95) Section 4.9 para 1
	[{static} Static means determinable at compile time,
	 using the declared properties or values of the program entities.]
which is what I thought static was supposed to mean, and why I though
Max(Coord'Digits, Value'Digits) *should* be static.

Now,
	Integer is a static scalar subtype (para 26),
	'Max is a language-defined attribute that is a function.
	In Integer'Max, the prefix denotes a static scalar subtype,
	the parameter and result types are scalar (para 22),
So,
	if Coord'Digits and Value'Digits are static expressions,
	Integer'Max(Coord'Digits, Value'Digits) is (para 6).

Also,
	T'Digits is an attribute reference that yields a scalar,
	so is a static expression if T is a static scalar subtype (para 7).

So all I have to show is that Coord and Value are static scalar subtypes,
and they are certainly scalar.  Para 26 tells me that the subtype of a
generic formal OBJECT of mode in out is not static, but these are generic
formal TYPES.

Oh DRAT.  I just saw it:
    "A static scalar subtype is an unconstrained scalar subtype
     whose type is NOT A DESCENDANT OF A FORMAL SCALAR TYPE".
Curse.

Thus it appears that I cannot do what I want in Ada 95 either:
	type T is digits E;
cannot mention any attribute of a generic formal type in the expression E.
I can't even say
	type T is digits Coord'Digits;
though of course I can still say
	type T is new Coord;


For several years I have gone around thinking that
    "One of the reasons Ada is a better language for numerical calculations
    than Fortran is that the body of an Ada package can adjust in sensible
    ways to the attributes of its numeric type parameters."
and now I find that this is not true.

WHY isn't it true?
WHY can't I define a package-internal type in terms of the precisions of
its formals?

Of course there is the trivial answer "because the standard says so".
But there has to be a more interesting answer than that.

A macro-expansion approach to generic packages would presumably have little
or no trouble with this construction.  Is this restriction in there to
support some other approach?  But why restrict the ability to adaptively
define floating point types, when the ability to adaptively define array
types is there?  How can the one be harder than the other?

And is there anything I can do to get what I want short of forcing the
package user to declare and provide a suitable type?

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.