Re: Ada '0x generics brain-fartz (long)

[mark_lundquist@my-deja.com]

When I first got this idea, I was thinking of it the way I described it
in my past -- as a new construct.  In the original post I called this
construct a "generic specialization".

But this morning I realized what it really is: a generalization of the
definition of a generic.  I became aware of this upon consideration of
the fact that there are no rules, beyond those for any ordinary
generic, governing the formal parameters for any
given "specialization".  The only rule pertains to the "new generic_
(package|procedure|function)_name" part, and that rule is that the
named generic be fully "provisioned" (that is, supplied with actuals,
like in an instantiation).  The effect of "partially binding" the
parameters of the base generic is simply a usage idiom, in which the
extending generic declares some formals which match some formals of the
base generic and then "passes them through".  But it need not pass
anything through, and in addition it may declare its own new formals
that have nothing to do with any formals of the base generic.
(Returning to the record extension analogy, the idea here is similar to
a type extension with discriminants).

Defining this idea in the language as "generics generalized" looks
pretty simple.  First we factor out part of the instantiation syntax as
its own construct:

    generic_provision ::=
        new <generic_name> [<generic_actual_part>];

The syntax for instantion gets rewritten as (e.g. for packages):

    generic_package_instantiation ::=
        <defining_program_unit_name> is <generic_package_provision>;

Now, the new, generalized syntax for a generic package becomes:

    generic_package_declaration ::=
        <generic_formal_part> [<generic_package_provision>]
package_specification;

(et cetera likewise for generic subprograms...)

All we did was add a new optional part.

A "baseless" generic (without the optional provision, that is, an Ada95-
compatible generic) can be thought of as implicitly an extension of an
anonymous, "null" base generic.  Not a particularly useful way of
thinking of it, except to emphasize that the new generic definition
really is the general case.  For instance,

    generic
        <whatever...>
    package Foo is
        <whatever...>
    end Foo;

is precisely equivalent to

    generic
    package Root_Of_All_Evil is
    end Root_Of_All_Evil;

    generic
        <whatever...>
    new Root_Of_All_Evil
    package Foo is
        <whatever...>
    end Foo;

A final note on the generalized generics idea... I see no reason for it
not to work seamlessly with generic child units.  A generic extending
another generic that is a child generic would have to be declared as a
child of the same parent as the generic being extended, e.g.:

    generic
    package Parent is
    end Parent;

    generic
    package Parent.Base_Child is
    end Parent.Base_Child;

    generic
    new Parent.Base_Child
    package Parent.Extended_Child is
    end Parent.Extended_Child;

    package P is new Parent;
    package BC is new P.Base_Child;
    pacakge EC is new P.Extended_Child;


The introduction of generic_provision also helps define the syntax for
my other idea, anonymous instantiation.  The <package_instance_name>
alternative for an <explicit_generic_actual_parameter> [RM12.3(5)]
would be replaced with <explicit_generic_actual_package>, defined as
follows:

    <explicit_generic_actual_package> ::=
        <package_instance_name> | <generic_package_provision>


all for now,
-- mark

Mark Lundquist
Rational Software




Sent via Deja.com
http://www.deja.com/