Version 1.1 of acs/ac-00071.txt

Unformatted version of acs/ac-00071.txt version 1.1
Other versions for file acs/ac-00071.txt

!standard 12.03(01)          03-08-04 AC95-00071/01
!class amendment 03-08-04
!status received no action 03-08-04
!status received 03-06-14
!subject Derived generic packages

From: Robert I. Eachus
Sent: Saturday, June 14, 2003  9:45 PM

I've been tossing around an idea of a language extenstion that has come
a long way from its roots.  But I'm getting to where I think it is very
much worth the effort.  I am going to explain the extension, then the
rationale behind it, which is of course the opposite of how it developed.

There are two useful ways to extend generics.  The first is to allow a
generic instantiation to provide a body. The syntax seems fairly trivial:

generic_instantiation ::=
      package defining_program_unit_name is
          new generic_package_name [generic_actual_part] [with body];
    | procedure defining_program_unit_name is
          new generic_procedure_name [generic_actual_part][with body];
    | function defining_designator is
          new generic_function_name [generic_actual_part] [with body];

And of course if "with body' appeared instead of instantiating the
orginial generic body, the programmer would have to supply a new body as
well (with of course the necessary elaboration check.)

If we add that, it makes sense to also allow a generic package
declaration to be a derived declaration and provide a new body.  But it
also makes sense to allow new generic parameters to be added:

generic_derived_package_declaration ::=
      generic_formal_part  package defining_program_unit_name is
                                    new package generic_package_name with
     end [[parent_unit_name.]identifier]

Obviously the semantic effect is as if there was a
generic_package_declaration with the additional generic formal
parameters following the list form the original generic package, and
with the new basic declarative items added at the end of the public and
private parts of the original generic.  I think that as far as with
clauses go, that withs of any units from the original also apply to the
generic, but for expository reasons it would probably be a good idea to
require that any necessary with and use clauses for the derived generic
be part of its declaration, even if that requires some duplication.  In
the (new, required) body of course the context clauses from both parent
units apply.

I thought about generic_derived_subprgram_declarations as well, but they
don't seem worth the effort.

So what is the benefit of doing all this?  Well any place that a generic
package parameter appears, an instance with a (new) body is allowed, or
an instance of a generic package type derived from the
generic_formal_package type.  It seems like a lot of work for an
extremely small benefit, until you think about things like container
libraries.  Of course you want to provide a heirarchy of container
types, and a user of the library could for example pass a dequeue where
a linked list is expected.  Chump chnage.  The standard library could
include both tasking save and non-safe versions of all the standard
packages, and since the tasking version would be derived from the
non-tasking version (or whatever structure is decided on) in any generic
that takes a generic formal container package, the user can choose at
instantiation time which version to pass.

More than that, for mix-ins, it is trivial to use mixins to create a new
generic package type which is derived from a single generic package
parent and mixes in other generics.

Finally add one other construct.  Allow generic declarations to be
preceeded by abstract.  Meaning of course that either the generic has to
be instantiated with a body, or of course an abstract generic package
can be derived from.  The derived generic would have to either also be
abstract, or provide a body/implementation.

Does this sound a lot like interface packages instead of interface
types?  That is actually where I started out.  I think that where I
ended up is at a useful extension to Ada that is somewhat orthogonal to
interface types.  There will be cases where the ideas overlap.  But I
think that in general generic package heirarchies and interface types
solve different problems.  There are areas where interface types are a
solution, and package heirarcies would be redundant.  There are other
cases where I tried to use the interface type proposal, and felt like I
had a hammer and a box of screws.

This is not a trivial language extension, but I also think that the
advantages are substantial.  However, the amount of compiler work
required seems relatively low. (The amount of work outside the
compilers, both in adding tests and in documention though makes the
change seem a lot larger.)


From: Robert Dewar
Sent: Sunday, June 15, 2003  1:43 AM

For me, aqny significant language extension proposal should have
two ingrediants:

1. A clear indication of user need, preferably emanating
fropm the application domain, rather than the language designers domain.

2. Convincing examples of scenarios where the feature would help. With
code using the extension, and equivalent code written under the
constraints of the current language.


From: Robert I. Eachus
Sent: Sunday, June 15, 2003  1:23 PM

Not a problem, as soon as I finish the 8129-010 bug, I'll get to work on
it.  Would you like me to rewrite AI-302, or some other container
library?  (And should I attempt to modify GNAT to see how much work it is?)

I just wanted to get the proposal on the table so that if anyone spots
any significant problems now, I can fix it before slinging code.  Of
course, slinging code is likely to find other problems, so it is
definitely a case of working back and forth.

Another binding set where I see this concept as tremendously useful is
ODBC bindings.


From: Tucker Taft
Sent: Monday, June 16, 2003  10:16 PM

This is an intriguing proposal, but I think generic
signature packages can provide much of the same
capability, and are in some ways more flexible.

I think the major limitation with generic
signature packages is a general one associated
with generics, namely that you can't pass them
a private type before it has been completed.
I sent in a proposal on how to fix this problem,
but it hasn't showed up as an AI (Randy?).

I think if we fix this problem with signatures
(which I think we should do), then they will
obviate the need for this rather complex
generic extension capability.


Questions? Ask the ACAA Technical Agent