Version 1.3 of ais/ai-00317.txt
!standard 12.07 (03) 03-02-05 AI95-00317/02
!class amendment
!status work item 02-10-06
!status received 02-10-06
!priority Medium
!difficulty Easy
!subject Partial Parameter Lists for Formal Packages
!summary
A formal package may have a partially specified set of actual parameters.
!problem
When a generic has more than one formal package parameter, it is often
important to link the two packages via their actuals. However, the
only way to link the packages is to specify one with no actuals, and
specify the other with all of its actuals. For example:
generic
with package Inst1 is new Gen1(<>);
with package Inst2 is new Gen2(Inst1.A, Inst1.B, ...);
...
package GP is ...
The problem is that there may be some actuals of the second formal
package which are not linked to the first one. The only way to
deal with this is to add more formal parameters to the generic GP to
specify the values for the remaining actual parameters. For example:
generic
type T1 is private;
type T2 is private;
with package Inst1 is new Gen1(<>);
with package Inst2 is new Gen2(Inst1.A, Inst2.B, FT3 => T1, FT4 => T2);
...
package GP is ...
Unfortunately, this approach defeats much of the advantage of formal
package parameters, which is to reduce the number of formals and simplify
the usage of a generic.
!proposal
A formal package parameter may specify some, but not all, of its actual
parameters. For example:
generic
with package Inst1 is new Gen1(<>);
with package Inst2 is new Gen2(Inst1.A, Inst2.B, others => <>);
...
package GP is ...
The parameters which are not specified may be referenced by name as
expanded names using the formal package as its prefix. For example,
Inst2.FT3 and Inst2.FT4 may be used later in the formal generic part
of GP or within the spec or body of GP. By contrast, the specified
actuals may not be so named, to avoid confusion between the properties
of the actual and those of the formal.
Similarly, any implicit declarations associated with a given parameter
of the formal package may be named using the formal package as a
prefix may only when the actual for the parameter is not specified.
With this proposal, the notation "(<>)" for its actual part is essentially
a short-hand for "(others => <>)."
!wording
Replace 12.7(3) with:
formal_package_actual_part ::=
(<>)
| [generic_actual_part]
| ([generic_association {, generic_association},] others => <>)
Any positional generic_associations shall precede any named
generic_associations.
Replace 12.7(5) with the following:
The actual shall be an instance of the template. If the
formal_package_actual_part is (<>) or (OTHERS => <>), then the actual
may be any instance of the template; otherwise, certain of the actual
parameters shall match between the actual instance and the formal
package:
* If the formal_package_actual_part includes generic_associations
as well as "OTHERS => <>", then only the actual parameters specified
explicitly in these generic_associations are required to match;
* Otherwise, all actual parameters shall match, whether the actual
parameter is given explicitly or by default.
The rules for matching of actual parameters between the actual instance
and the formal package are as follows:
Replace 12.7(10) with the following:
The visible part of a formal package includes the first list of
basic_declarative_items of the package_specification. In addition,
for each actual parameter that is not required to match, a copy of the
declaration of the corresponding formal parameter of the template
is included in the visible part of the formal package.
!discussion
This is intended to be a natural generalization of the two capabilities
currently provided for specifying actual parameters of a formal package.
By providing this "mid-point" where some but not all of the parameters
are specified, the formal package capability becomes significantly more
useful, without measurably increasing the complexity of supporting the
capability.
Semantic issues/choices:
1) Presumably (others => <>) is exactly equivalent to (<>).
2) We don't talk about the what implicit declarations are
included in the visible part of the formal package
when the actuals are partially specified. Can we
just assume the implementor will "do the right thing"?
Perhaps we should say that if and only if the copy of a
formal type is included in the visible part, the
associated implicit primitive operation declarations
are included.
3) The wording seems a bit convoluted.
!examples
-- Imagine a generic signature package with
-- two formal parameters:
generic
type T is private;
Obj : T
package Sig is end;
-- Now imagine there is a layered abstraction that
-- wants two instances of this signature, and
-- wants them to share the same type T, but not
-- necessarily the same object "Obj."
generic
with package P1 is new Sig(<>);
with package P2 is new Sig(P1.T, others => <>);
package Layered_Abstraction is
X : P1.T := P2.Obj; --
--
--
--
...
end Layered_Abstraction;
---------
Note that this exact situation came up while I was
working on the physical units AI. I wanted to pull
out some of the nested generics from the large "System_Of_Units"
generic. This would require the Unit_Signature generic
signature to have at least one additional parameter,
the Names_Of_Dimensions:
generic
type Names_Of_Dimensions is (<>);
Name : in String;
Exponents : in Exponent_Array;
Scale_Factor : in Scale_Type;
type Value is digits <>;
package Unit_Signature is end;
But if I wanted to use this in something that
constructed a "product" unit from two individual
units:
generic
with package Unit_A is new Unit_Signature(<>);
with package Unit_B is new Unit_Signature(Unit_A.Names_Of_Dimensions, others => <>);
package Product_Unit is
type Value is ...
...
end Product_Unit;
I would need to be sure that the Names_Of_Dimensions types were
the same. With the Ada 95 rule, I would have to pass in all of the
other parameters separately to be able to force a match on
just one of them:
generic
with package Unit_A is new Unit_Signature(<>);
Unit_B_Name : in String;
Unit_B_Exponents : in Exponent_Array;
Unit_B_Scale_Factor : in Scale_Type;
type Unit_B_Value is digits <>;
with package Unit_B is new Unit_Signature(Unit_A.Names_Of_Dimensions,
Unit_B_Name, Unit_B_Exponents, Unit_B_Scale_Factor, Unit_B_Value);
package Product_Unit is
type Value is ...
...
end Product_Unit;
This is clearly much less useful, and creates an asymmetric requirement
when instantiating, where information about Unit_A can be passed
in using a single signature instance, whereas Unit_B requires
four additional formal parameters and then a largely redundant
signature instance as well.
!ACATS test
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent