Re: Generic formal package parameter question

[Brian Rogoff <bpr@shellx.best.com>]

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