default formal parameters in generic declarations

[Eric Hughes <eric.eh9@gmail.com>]

I've spent some time reading ARM2005/12. Generic Units.  Formal
objects and subprograms can have default values.  Formal types and
packages cannot.  Could someone point me to the discussion where this
inconsistency was decided to be a good thing?

I have a certain sympathy with this absence with regard to packages,
because Ada as yet has no expression for partial specification of
packages, package derivation other than child packages, or
(consequentially) a declaration "abstract package".  The same,
however, does not hold for types, not in the least.

I have a couple of use cases where I'd like default values for formal
packages.  Not having them destroys concision.  I can get something of
the same effect by using separate names for the default and non-
default cases and forwarding all the definitions with renaming
statements and the like.  This is error-prone and clunky.

Here's one use case. Last year I had occasion to implement a certain
fraction of aspect-oriented programming with C++ templates.  (The
restriction was that all cut-points have to be explicit.)  An aspect
is a separate class.  It attaches to its underlying class as a generic
(template) parameter when instantiating the underlying class.  Each
aspectable class also has a default aspect class, which is null.  The
null aspect is a default generic parameter.  This means that a user
need not be aware of the aspect at all (which is the ordinary case).

In the non-generic case, the aspect contained code and state,
instantiating the cut-points with augmented utility.  I was using an
aspect to do white-box unit testing on the inner behavior of a novel
kind of scheduler.  This facilities was critical to getting the system
running right.  And this all worked without the preprocessor.

I would like to implement this in Ada, but the absence of a default
package parameter means that instantiation is horribly clunky and that
only the most dedicated would use it.