default formal parameters in generic declarations

default formal parameters in generic declarations

[Eric Hughes]

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.

Re: default formal parameters in generic declarations

[Robert A Duff]

Eric Hughes <eric.eh9@gmail.com> writes:

> 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?

It is not a good thing.

- Bob

Re: default formal parameters in generic declarations

[Eric Hughes]

Eric Hughes <eric....@gmail.com> writes:
> 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?

On Mar 2, 10:42 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> It is not a good thing.

The absence of this expression is not a good thing, but my question
was more about the tradeoffs, not in the language itself, but in the
whole context of the creation of the language.  Was it considered too
late to be understood?  Were there too many prerequisites?  Was not a
high enough priority?  _On balance_ it must have been a good thing,
because it didn't happen.  I am assuming it was considered.

Re: default formal parameters in generic declarations

[Dmitry A. Kazakov]

On Sun, 2 Mar 2008 11:40:38 -0800 (PST), Eric Hughes wrote:

> Eric Hughes <eric....@gmail.com> writes:
>> 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?
> 
> On Mar 2, 10:42 am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> It is not a good thing.
> 
> The absence of this expression is not a good thing, but my question
> was more about the tradeoffs, not in the language itself, but in the
> whole context of the creation of the language.  Was it considered too
> late to be understood?  Were there too many prerequisites?  Was not a
> high enough priority?  _On balance_ it must have been a good thing,
> because it didn't happen.  I am assuming it was considered.

I don't know anything about how the decision was made, but a default
package "value" would require in my view certain mechanisms Ada presently
lacks. In order to be usable the "value" should take actuals of other
formal parameters:

generic
   type A is ...;
   with package B is new Boo (A) := Default; -- Default depends on A
package Foo is ...

Here Default is in fact a generic package rather than an instance of. There
could be many ways to resolve this, from automatic instantiation (certainly
not Ada) to conditional instantiations of defaults within the specification
part of Foo (might be problematic due to visibility issues). 

IMO, it is better (as always) to get rid of generics. Default values of
packages are in fact inheritable interfaces. Thus inheritance should be the
way. I would extend this part of the language rather than generics.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: default formal parameters in generic declarations

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> IMO, it is better (as always) to get rid of generics. Default values of
> packages are in fact inheritable interfaces. Thus inheritance should be the
> way. I would extend this part of the language rather than generics.
> 

Supposedly, removal of generics will also remove the
tags from concrete types?

How do you deal with what is now usually a generic
swap procedure?

Re: default formal parameters in generic declarations

[Stephen Leake]

Eric Hughes <eric.eh9@gmail.com> writes:

> 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.

I don't see why this would be "horribly klunky"; they typical user
will do:

package My_Instance is new Generic_Package 
    (Aspect_Package => Null_Aspect_Package,
     foo => Bar,
     ...);

You are requesting the ability to do this instead:

package My_Instance is new Generic_Package 
    (foo => Bar,
     ...);

I agree it's a little nicer, but that big a deal.

-- 
-- Stephe

Re: default formal parameters in generic declarations

[Dmitry A. Kazakov]

On Mon, 03 Mar 2008 12:15:45 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> IMO, it is better (as always) to get rid of generics. Default values of
>> packages are in fact inheritable interfaces. Thus inheritance should be the
>> way. I would extend this part of the language rather than generics.
> 
> Supposedly, removal of generics will also remove the
> tags from concrete types?

Only from non-by-reference ones. Actually Ada already has the keyword
"tagged" which could read "do it by reference and please keep the tag."

> How do you deal with what is now usually a generic
> swap procedure?

type Copyiable is interface ...;
    -- All the things with an assignment and copy constructor (initializer)

A. Class-wide Swap

procedure Swap (Left, Right : in out Copyiable'Class) is
   Temp : Copyiable'Class := Left;
begin
   Left := Right;
   Right := Temp;
end Swap;

B. Primitive Swap (doubly-dispatching with only the diagonal elements
allowed).

procedure Swap (Left, Right : in out Copyiable) is
   Temp : Copyiable'Class := Left;
begin
   Left := Right;
   Right := Temp;
end Swap;

P.S. One problem I didn't know how to solve was the constraints on the
combinations of the argument's types. A generic solution is
pre-constrained, so that it cannot handle some cases at all. For Swap you
might wish to detect all non-diagonal cases which would raise
Constraint_Error at compile time. Clearly, when the tags are known
statically (as with generics) and (for the variant A) the body is inlined,
for the variant B without the body, the compiler could give a warning. The
problem is how to convert warning into an error. I guess that contracted
exceptions could be a solution.

P.P.S. Another problem is adding interfaces to existing types. This is
solved by supertyping.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: default formal parameters in generic declarations

[Randy Brukardt]

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:a520f018-097c-406b-a3e3-387a28d38216@s8g2000prg.googlegroups.com...
> Eric Hughes <eric....@gmail.com> writes:
> > 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?
>
> On Mar 2, 10:42 am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
> > It is not a good thing.
>
> The absence of this expression is not a good thing, but my question
> was more about the tradeoffs, not in the language itself, but in the
> whole context of the creation of the language.  Was it considered too
> late to be understood?  Were there too many prerequisites?  Was not a
> high enough priority?  _On balance_ it must have been a good thing,
> because it didn't happen.  I am assuming it was considered.

It surely was considered for the most recent language update, because I
proposed it. See AI-299. I thought it would give up more flexibility for
defining a set of containers libraries. It was not approved mainly because
of two reasons: the proposed syntax wasn't liked much, but no one had a
better idea; and because it came up at a meeting which many people consider
the low point of the Ada development -- it was mostly a lot of dubious
arguments over one feature or another, and about the only things that got
accomplished was by killing proposals. (I seriously considered quitting
after that meeting.) Presumably, at least some people didn't think it was
important enough.

The net effect is that IMHO there is no *good* reason that Ada doesn't have
such defaults (now); they just got swept up in a tide of negativity. As for
the question of why they were omitted in the first place, I can't say (I
wasn't there). I would suspect that their value wasn't completely understood
at the time; I don't recall having encountered default parameters of any
kind before seeing Ada.

                     Randy Brukardt, ARG Editor

Re: default formal parameters in generic declarations

[Dr. Adrian Wrigley]

On Mon, 03 Mar 2008 07:42:40 -0500, Stephen Leake wrote:

> Eric Hughes <eric.eh9@gmail.com> writes:
> 
>> 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.
> 
> I don't see why this would be "horribly klunky"; they typical user
> will do:
> 
> package My_Instance is new Generic_Package 
>     (Aspect_Package => Null_Aspect_Package,
>      foo => Bar,
>      ...);

Perhaps I am being a little stupid, but how does this work?
Could you flesh out the detail a little more?

What kind of parameter is Aspect_Package? and where does
the Null_Aspect_Package come from?
--
Adrian

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 3, 2:17 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> IMO, it is better (as always) to get rid of generics.

Well, if you don't like generics, then enhancing their utility will
certainly seem like a waste of time.

> Default values of packages are in fact inheritable interfaces.

As to this assertion, I believe this to be false.  I won't argue it
here (it's beside my point), but I can recommend how C++ libraries
have come to use "traits" (their jargon) classes as template arguments
for a counterexample.

Eric

Re: default formal parameters in generic declarations

[Eric Hughes]

Eric Hughes <eric....@gmail.com> writes:
> 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.

On Mar 3, 5:42 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> I don't see why this would be "horribly klunky"; they typical user
> will do:

For a single package instantiation, a default formal package would
have the same benefit as a default formal subprogram.  It removes from
a programmer's mind a detail that may not be relevant, and it removes
from a less-experienced such mind a barrier to entry.

I said "horribly klunky" specifically in reference to instantiation of
aspects.  The problem arises because, in general, an aspect _ought_ to
have access to the internal state of the package for which it is
acting as an aspect.  That means that a base package requires an
aspect parameter to instantiate it at the same time as the aspect
requires a base package to instantiate it.  The hard problem I had to
figure out was how to avoid infinite regression.  In C++, the solution
was to rely upon a detail of template instantiation where a self-
reference to a class itself with the template parameters of its
instantiation refers _not_ to the templated base class but to the
class being instantiated, and so thus creates (de facto) an anonymous
type whose introduction breaks the regression.

If that sounds complicated to understand, it is.  The minimal syntax
to declare and to instantiate is not simple.  In fact, it's really
quite a mess, and I couldn't figure out how to simplify it (even more--
I have some idea that it's minimal).  Requiring an ordinary user to
learn even some this detail simply to use the class in its ordinary
way is a poor information-hiding practice.

Eric

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 3, 8:43 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> It surely was considered for the most recent language update, because I
> proposed it. See AI-299.

Thank you.  That's the exact sort of reference I was hoping for.

> The net effect is that IMHO there is no *good* reason that Ada doesn't have
> such defaults (now); they just got swept up in a tide of negativity.

The "good", apparently, was a removal from attention and a freeing up
of mental space.  That's a short-term benefit to a committee,
unfortunately, and not a long-term benefit to a community.

Eric

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 4, 6:50 am, "Dr. Adrian Wrigley"
<a...@linuxchip.demon.co.uk.uk.uk> wrote:
> Perhaps I am being a little stupid, but how does this work?
> Could you flesh out the detail a little more?

You can see it in action in the C++ I wrote.  It was for a prototype
version of media server inside Gnash, whose source is available by
anonymous CVS.  Look, in the source tree under cygnal/, for Aspect.hpp
and the sources and unit tests under ACT/ that use it.

I don't have an Ada version running at present.  I'm just starting to
work on one, but as it's an unfunded personal project, I won't offer
anything as to schedule.

Eric

Re: default formal parameters in generic declarations

[Randy Brukardt]

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:d84f0434-bace-4b99-b10d-f4a56807eacd@d62g2000hsf.googlegroups.com...
> On Mar 3, 8:43 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > It surely was considered for the most recent language update, because I
> > proposed it. See AI-299.
>
> Thank you.  That's the exact sort of reference I was hoping for.
>
> > The net effect is that IMHO there is no *good* reason that Ada doesn't
have
> > such defaults (now); they just got swept up in a tide of negativity.
>
> The "good", apparently, was a removal from attention and a freeing up
> of mental space.  That's a short-term benefit to a committee,
> unfortunately, and not a long-term benefit to a community.

Well, keep in mind that if a language update has too many "nice-to-have"
features, the implementation costs go up and that reduces (or in the worst
case, eliminates) the number of implementations available. Also, more
features mean more definitional and educational complexity. So there are
costs beyond just plain ease of use to consider. Looking back at the old
minutes, we had a straw poll where about half of the people present thought
that this feature was not important enough. That's a pretty significant
number (I don't recall many other features that had that level of apathy).

Another data point is that this AI is not one that I think of when asked
what I wished we had been able to do with the Amendment. So even I don't
view it as that critical. As such, it makes sense that it got left out in
order to keep the size of the changes manageable.

                                   Randy.

Re: default formal parameters in generic declarations

[Stephen Leake]

Eric Hughes <eric.eh9@gmail.com> writes:

> Eric Hughes <eric....@gmail.com> writes:
>> 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.
>
> On Mar 3, 5:42 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> I don't see why this would be "horribly klunky"; they typical user
>> will do:
>
> For a single package instantiation, a default formal package would
> have the same benefit as a default formal subprogram.  It removes from
> a programmer's mind a detail that may not be relevant, and it removes
> from a less-experienced such mind a barrier to entry.

Right.

> I said "horribly klunky" specifically in reference to instantiation of
> aspects.  The problem arises because, in general, an aspect _ought_ to
> have access to the internal state of the package for which it is
> acting as an aspect.  

Right. That's one reason I don't think aspect-based programming is all
that useful.

> That means that a base package requires an aspect parameter to
> instantiate it at the same time as the aspect requires a base
> package to instantiate it. The hard problem I had to figure out was
> how to avoid infinite regression. 

Ok.

> In C++, the solution was to rely upon a detail of template
> instantiation where a self- reference to a class itself with the
> template parameters of its instantiation refers _not_ to the
> templated base class but to the class being instantiated, and so
> thus creates (de facto) an anonymous type whose introduction breaks
> the regression.

Ok. Did you find a similar mechanism in Ada yet? Does limited with help?

> If that sounds complicated to understand, it is.  The minimal syntax
> to declare and to instantiate is not simple.  In fact, it's really
> quite a mess, and I couldn't figure out how to simplify it (even more--
> I have some idea that it's minimal).  Requiring an ordinary user to
> learn even some this detail simply to use the class in its ordinary
> way is a poor information-hiding practice.

Ok. I can see that this might justify "horribly klunky".

-- 
-- Stephe

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 4, 11:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Looking back at the old
> minutes, we had a straw poll where about half of the people present thought
> that this feature was not important enough. That's a pretty significant
> number

I can understand why so many people did not understand the
significance of this feature.  I know I would not have then.  It
wasn't until just the last two years or so that I've done any really
significant generic programming in C++.  Let me begin to rectify that
deficiency in understanding its significance.

The real difficulty with not have package defaults begins the second
layer of generic instantiation, not the first.  For just one layer (by
that I mean a simple instantiation of a generic) it's certainly easy
enough to put in a default manually.  But what then if the package in
which this happens is itself generic, and, furthermore, incurs a
dependency of this instantiation on its own formal parameters?  This
is the completely typical case, to pick an example, for a generic
package "A" that's configurable with a storage pool.  Another generic
package "B" should (in most cases), as a matter of information hiding,
also have a storage pool parameter of its own that it forwards to
package "A" at its instantiation, but should also allow a different
storage pool for "A".  (I don't know why you'd want this insofar as
storage pools go, but they're just the example parameter here.)
Without a default formal parameter, there is no way to get both of the
following desiderata simultaneously:
    1. Forwarding of the "B" parameter to "A" and elision of a
duplicate parameter when these are the same.
    2. Ability to override the forward and specify a separate
parameter in "B" for use in "A".
You can get 1 by just hard-coding the instantiation parameter for "B",
but that eliminates 2.  You can get 2 by using an extra parameter in
"B", but that eliminates the second half of 1.

Even with just two layer of instantiation this is feasible, but, in
the phrase I used earlier, "horribly klunky" (particularly with non-
linear references).  So here's the biggest problem: You cannot get
simultaneously both arbitrarily deep layering and concision in formal
parameters for ordinary usage.  Without defaults, every single
ordinary usage has the same notational complexity as an arbitrary
usage in full generality.  This severely limits the practical utility
of generic programming in Ada to simple cases.  And I say that
anything that limits the depth of abstraction layering is a _prima
facie_ bad thing.  It breaks information hiding in a bad way.

As a coda, I wish to add that this practice is not hypothetical.  The
sophistication of some of the generic (template) programming in the
Boost C++ library is excellent and worth imitating.

Re: default formal parameters in generic declarations

[Eric Hughes]

Eric Hughes <eric....@gmail.com> writes:
> The problem arises because, in general, an aspect _ought_ to
> have access to the internal state of the package for which it is
> acting as an aspect.

On Mar 5, 6:11 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Right. That's one reason I don't think aspect-based programming is all
> that useful.

I myself find the claims for the utility of AOP a bit overblown.  It
is, however, very good for observational applications: logging,
monitoring, defect correction, etc.  These are essentially "read only"
ways of using the internal state of an object.  In the general case,
getting anything correct seems hard enough, much less making anything
generically useful.  I remain

I should also say that one of the main reasons I did this was that
envisioned four different use cases: a zero-overhead case for ordinary
usage, a logging case for tracking down problems, an performance-
tuning case at the initial phase of deployment, and the unit testing
case.  Getting zero-overhead meant using an aspect that could compile
down into nothing when needed.

[re: circular generic references]
> Did you find a similar mechanism in Ada yet? Does limited with help?

I'm working on it.  I am certain to use "limited with", yes.  I
suspect that construct is necessary, but I cannot make the argument
one way or the other as yet.

Eric

Re: default formal parameters in generic declarations

[Georg Bauhaus]

Eric Hughes wrote:

> Even with just two layer of instantiation this is feasible, but, in
> the phrase I used earlier, "horribly klunky" (particularly with non-
> linear references).  So here's the biggest problem: You cannot get
> simultaneously both arbitrarily deep layering and concision in formal
> parameters for ordinary usage.

By way of speculation, can nesting, to the extent it is absent from C++,
lead to at least a partial solution of this problem?

package News4 is

   type Performance_Tuning is interface;

   function Null_Tuning return Performance_Tuning'Class;

   generic
      Tuner: Performance_Tuning'Class := Null_Tuning;
   package B is

      generic
         Tuner: Performance_Tuning'Class := B.Tuner;
      package A is end;

   end B;

end News4;


To some extent, this view would require building software with "towers"
of building blocks in mind, rather than patterns of cobblestone, so to
speak.


> As a coda, I wish to add that this practice is not hypothetical.  The
> sophistication of some of the generic (template) programming in the
> Boost C++ library is excellent and worth imitating.

Again by way of speculation, and as an example, the Boost
parsing facilities have a counterpart in Ada that just works
differently, using access to nested functions.
GNAT.Spitbol.Patterns solves the same practical problems
as the spirit parsers, and more. There might be a small
overhead because pattern construction does not occur at
compile time, but then Spitbol.Patterns is actually more powerful.

I'm noting all this only because I should think there is some value
in nesting that, just maybe, is easily overlooked.

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 6, 2:32 am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> By way of speculation, can nesting, to the extent it is absent from C++,
> lead to at least a partial solution of this problem?
[example deleted]

The technique you outlined is applicable insofar as name space
manipulation goes, yes.  I note here that your example uses a formal
default subprogram.

The problem, really, is that an aspect is larger than a single
function.  An aspect has state, a state that augments the state of the
package for which it is an aspect.  State, in Ada, is captured in
types.  For example, a null aspect has no state, represented by a null
record.  Ada currently has neither formal defaults for types or
packages; I've been focusing on packages.  If Ada had a syntax for a
formal default type, I might be able to shoehorn everything through
that, at the cost of some contortion of syntax, but that's not
possible either.

> I'm noting all this only because I should think there is some value
> in nesting that, just maybe, is easily overlooked.

Certainly the point about nesting you make is true.  It's one way of
addressing the self-reference problem.  Yet it doesn't rise to a
complete approach.

Eric

Re: default formal parameters in generic declarations

[Ludovic Brenta]

Eric Hughes writes:
> On Mar 6, 2:32 am, Georg Bauhaus wrote:
>> By way of speculation, can nesting, to the extent it is absent from C++,
>> lead to at least a partial solution of this problem?
> [example deleted]
>
> The technique you outlined is applicable insofar as name space
> manipulation goes, yes.  I note here that your example uses a formal
> default subprogram.
>
> The problem, really, is that an aspect is larger than a single
> function.  An aspect has state, a state that augments the state of the
> package for which it is an aspect.  State, in Ada, is captured in
> types.  For example, a null aspect has no state, represented by a null
> record.  Ada currently has neither formal defaults for types or
> packages; I've been focusing on packages.  If Ada had a syntax for a
> formal default type, I might be able to shoehorn everything through
> that, at the cost of some contortion of syntax, but that's not
> possible either.

The actual subprogram may very well be nested in a package that
declares all the necessary types and variables to keep the state.
And, in Ada 2005, it is even possible to pass a null
access-to-subprogram as the formal to represent a "null aspect".

-- 
Ludovic Brenta.

Re: default formal parameters in generic declarations

[Georg Bauhaus]

Ludovic Brenta wrote:
> Eric Hughes writes:
>> On Mar 6, 2:32 am, Georg Bauhaus wrote:
>>> By way of speculation, can nesting, to the extent it is absent from C++,
>>> lead to at least a partial solution of this problem?
>> [example deleted]
>>  I note here that your example uses a formal
>> default subprogram.

> The actual subprogram may very well be nested in a package that
> declares all the necessary types and variables to keep the state.

Yes, and in C, too, a local static struct might keep state.
But actually, the function in the example,

generic
   Additional_Operations_Object: Functionality_Interface'Class :=
      Add_Ops_Factory.New_Object;
package Foo is

   type T is ...

is used only to provide a default object of a suitable abstract
type (which could be Any'Class) on instantiation. This object
can be overridden, passed downwards to other instantiations,
"intercepted" by different Functionality_Interface'Class objects...
But, as Eric has explained, going along this path does not
yet lead to complete solution.

Re: default formal parameters in generic declarations

[Eric Hughes]

On Mar 7, 3:51 am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
[another example elided]
> This object
> can be overridden, passed downwards to other instantiations,
> "intercepted" by different Functionality_Interface'Class objects...
> But, as Eric has explained, going along this path does not
> yet lead to complete solution.

I would like to expand upon this.  The essential deficit is that
subprogram instantiation only addresses the middle of the life cycle
of an object, but neither it's beginning nor end.  During the middle
of the life cycle, there must be a way of hooking into the operation
of an object.  In AOP parlance, these are called cut points and their
manifestation is a subprogram (either by call or in-line).  Yet this
does not address memory allocation of the state of an aspect, which
must, in general, be allocated one-to-one (aspect-to-object).  The
easiest pattern for this simply inserts the aspect state into the
object; this is efficient and avoids explicit deallocation.  There are
other ways one might conceive of doing this, and all of them require
action at the beginning and end of the life cycle.  You could
accomplish this, say, with a controlled base type and an associative
array for arbitrary dereference.  Without type or package formal
parameters, however, it's impossible to get the aspect state simply
inserted.

Eric