* Generic formal package parameter question
@ 1997-08-21 0:00 Brian Rogoff
1997-08-22 0:00 ` Tucker Taft
0 siblings, 1 reply; 3+ messages in thread
From: Brian Rogoff @ 1997-08-21 0:00 UTC (permalink / raw)
There are two forms for generic formal package parameters
with package P is new G(<>);
or
with package P is new G( Q1, Q2, ..., QN );
Why there isn't an intermediate form where some, but not necessarily
all, of the parameters appear in the parameter list, allowing us to
better represent the relationships between the parameters?
For example, suppose we have two generic signature packages, Assignable
and Composable
generic
type Assignable_Type is limited private;
with procedure Assign( From : in out Assignable_Type;
To : out Assignable_Type );
package Assignable is end;
generic
type Comparable_Type is limited private;
with function Compare ( X, Y : Comparable_Type )
return Comparison_Type; -- Boolean or three-valued
package Comparable is end;
and we want a third package to have a generic formal parameter which is
both Assignable and Comparable. I'd like to be able to express it like
this
generic
type Value_Type is private;
with package Comparable_Values is
new Comparable( Value_Type, <> ); -- Illegal
with package Assignable_Values is
new Assignable( Value_Type, <> ); -- Illegal
package Assignable_Comparable is end;
but Ada forces an all or nothing approach here, and I have to choose
nothing (<>) rather than be able to express those constraints that I can,
in this case that both of the signature packages are instantiated with
Value_Type. This seems really against the spirit of Ada to me, so I'm
curious as to the reasons for this limitation.
-- Brian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Generic formal package parameter question
1997-08-21 0:00 Generic formal package parameter question Brian Rogoff
@ 1997-08-22 0:00 ` Tucker Taft
1997-08-22 0:00 ` Brian Rogoff
0 siblings, 1 reply; 3+ messages in thread
From: Tucker Taft @ 1997-08-22 0:00 UTC (permalink / raw)
Brian Rogoff (bpr@shellx.best.com) wrote:
: There are two forms for generic formal package parameters
: with package P is new G(<>);
: or
: with package P is new G( Q1, Q2, ..., QN );
: Why there isn't an intermediate form where some, but not necessarily
: all, of the parameters appear in the parameter list, allowing us to
: better represent the relationships between the parameters?
: For example, suppose we have two generic signature packages, Assignable
: and Composable
: generic
: type Assignable_Type is limited private;
: with procedure Assign( From : in out Assignable_Type;
: To : out Assignable_Type );
: package Assignable is end;
: generic
: type Comparable_Type is limited private;
: with function Compare ( X, Y : Comparable_Type )
: return Comparison_Type; -- Boolean or three-valued
: package Comparable is end;
: and we want a third package to have a generic formal parameter which is
: both Assignable and Comparable. I'd like to be able to express it like
: this
: generic
: type Value_Type is private;
: with package Comparable_Values is
: new Comparable( Value_Type, <> ); -- Illegal
: with package Assignable_Values is
: new Assignable( Value_Type, <> ); -- Illegal
: package Assignable_Comparable is end;
: but Ada forces an all or nothing approach here, and I have to choose
: nothing (<>) rather than be able to express those constraints that I can,
: in this case that both of the signature packages are instantiated with
: Value_Type. This seems really against the spirit of Ada to me, so I'm
: curious as to the reasons for this limitation.
During the 9X design process, whenever we posed a question like this,
we eventually learned to put ourselves in the following mind set:
What is the simplest set of rules that will give us the essential
power and flexibility desired (and not get tossed out completely
by the distinguished reviewers ;-)?
One can always make features more complicated in an attempt to match
perfectly all problems, but during the design process we had to focus on
providing language features as building blocks, which programmers could
combine in various ways to solve their various problems.
In particular, I believe there is a legal combination that is roughly
equivalent to your solution. First, it is useful to recognize that any use
of (<>) is functionally equivalent to having a bunch of additional formal
parameters, one per parameter of the template package, and then
use those parameters in the formal package as actuals. Furthermore,
all formal subprogram parameters can be defaulted, presuming there
is an appropriate "use" clause in effect.
For example:
with package Assignable_Values is new Assignable(<>);
is functionally equivalent to:
type Assignable_Type is private;
with procedure Assign( From : in out Assignable_Type;
To : out Assignable_Type ) is <>;
with package Assignable_Values is new Assignable(
Assignable_Type, Assign);
Clearly (<>) is more convenient for the instantiator, but it
does not actually add any additional semantic capability.
Given that (<>) can be replaced by explicit (possibly defaulted)
parameters, any sort of partial (<>, param, <>) could also be replaced by
explicit parameters. On the other hand, there are things which
the version with explicit parameters can do that the (<>) form
cannot, such as indicate that two instances must have the same
actual parameter for corresponding formal parameters, as above.
In any case, switching over to (<>) for both of your formal
packages is not equivalent to the above. However, the following
is equivalent, albeit not quite as convenient (though the use of
a "use" clause at the instantiation point seems to provide
adequate convenience):
generic
with package Comparable_Values is
new Comparable( <> );
use Comparable_Values;
with procedure Assign( From : in out Comparable_Type;
To : out Comparable_Type ) is <>;
with package Assignable_Values is
new Assignable( Comparable_Type, Assign);
package Assignable_Comparable is end;
Now an instantiation of this could be:
with C_Values;
with A_Values; use A_Values; -- "use" makes operation(s) visible
package A_C_Values is new Assignable_Comparable(
Comparable_Values => C_Values,
Assignable_Values => A_Values);
-- "Assign" defaults properly
In this particular case, you could actually drop the
"Assignable_Values" formal completely, since it is
not adding anything over and above the "with procedure Assign".
The instantiator would then just "use" the appropropriate
instance of the generic signature Assignable, rather than
passing it in explicitly as a parameter. However, that may
appear a bit odd at the instantiation point. I.e:
with C_Values;
with A_Values; use A_Values;
package A_C_Values is new Assignable_Comparable(C_Values);
since the relevant part of A_Values is all coming in via defaulted
formal subprogram parameters.
: -- Brian
--
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Burlington, MA USA
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Generic formal package parameter question
1997-08-22 0:00 ` Tucker Taft
@ 1997-08-22 0:00 ` Brian Rogoff
0 siblings, 0 replies; 3+ messages in thread
From: Brian Rogoff @ 1997-08-22 0:00 UTC (permalink / raw)
On Fri, 22 Aug 1997, Tucker Taft wrote:
>>... my half-baked proposal for partial parametrization deleted ...
>
> During the 9X design process, whenever we posed a question like this,
> we eventually learned to put ourselves in the following mind set:
> What is the simplest set of rules that will give us the essential
> power and flexibility desired (and not get tossed out completely
> by the distinguished reviewers ;-)?
Damn those distinguished reviewers! :-) I don't envy the job of having to
argue with dozens of intelligent programmers who may not share the same
opinions as you on what is "right". I think you and the reviewers did a
great job, or I wouldn't be here complaining.
I'd like to point out that the example I posted was the smallest one I
could make up which looked like real code (rather than a contrived example
with carnivorous cows or salacious skiers) and still showed the problem.
Any workaround will appear acceptable with an example this small, indeed
generic formal package parameters are most useful when you have lots of
parameters and aren't so necessary otherwise. I have a lot of code with
lots of generic package parameters; these workarounds are much less
palatable with more realistic examples. I'll post these if you wish, but I
think the example I gave is sufficient.
> One can always make features more complicated in an attempt to match
> perfectly all problems, but during the design process we had to focus on
> providing language features as building blocks, which programmers could
> combine in various ways to solve their various problems.
I agree with this design philosophy, and in the case of multiple
inheritance, I think the right choice was made. In this case, if there is
no hidden cost that I'm missing, I think the more general form that I'm
proposing, or something like it, would have been slightly better.
> In particular, I believe there is a legal combination that is roughly
> equivalent to your solution. First, it is useful to recognize that any use
> of (<>) is functionally equivalent to having a bunch of additional formal
> parameters, one per parameter of the template package, and then
^^^^^^^^
Clearly you've been corrupted by some other language! :-)
> Clearly (<>) is more convenient for the instantiator, but it
> does not actually add any additional semantic capability.
Yes. I don't think my proposal adds any additional semantic capability,
but it allows one to express more compactly, and I believe more "readably",
the intentions of the programmer. This is what I meant by "the spirit of
Ada".
So, is there any "hidden gotcha" in there that makes this very hard to
implement?
-- Brian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1997-08-22 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-21 0:00 Generic formal package parameter question Brian Rogoff
1997-08-22 0:00 ` Tucker Taft
1997-08-22 0:00 ` Brian Rogoff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox