[RFC] Deferred Partial Instantiation of Generic Specifications

[jere-software]

Link to text: https://github.com/jeremiahbreeden/ada-spark-rfcs/blob/topic/deferred_partial_instantiation/considered/rfc-deferred-partial-instantiation.rst

This is to suggest providing a means of creating a simpler specification of a generic by allowing some parameters of the generic to be specified manually while leaving the rest to the client instantiator. In short it allows for specification:

    generic
       type Type1 is private;
       type Type2 is limited private;
       type Type3(<>);
       with procedure Something(Param1 : Type2; Param2 : Type3);
       with function Image(Value : Type1) return String;
    package My_Package is
       procedure Yay(Value : Type1);  -- calls Image internally
       -- Other Stuff
    end My_Package;

to be simplified (notionally) in a later generic:

    generic
       type Type1 is private;
       with function Image(Value : Type1) return String;
    package My_Client_Package is
       -- Same public API as before
    end My_Client_Package;

using the syntax:

    generic
       type Type1 is private;
       with function Image(Value : Type1) return String;
    package My_Client_Package is new My_Package
       (Type1     => Type1,
        Type2     => Integer,
        Type3     => String,
        Something => Something_For_Integer_And_String,
        Image     => Image);

without needing to provide scaffolding or package chaining.

[sttaft]

Nice proposal. Need to decide how this interacts with formal packages. In particular, would any instance of the original generic package that matched the partial instantiation be considered an instance of this new generic, and similarly, would any instance of this new generic be considered an instance of the original generic?

[jere-software]

@sttaft Thanks. I tried updating the proposal with how to handle it. I marked it as OPTIONAL. If it makes the proposal untenable, then it could easily be pulled back out and we could just consider them separate generic package specifications, but I would like to at least explore allowing them to be used interchangeably (with respect to the formal values supplied). I will say I am getting into a realm where I am not 100% good with the terminology so suggestions on how to fix any of it are appreciated. Hopefully it at least can be deciphered from the examples if I botched the wording.

[sttaft]

Thanks for looking into the implications. I think you want the matching to work both ways, pretty much as you have proposed. Take care, -Tuck

…

On Tue, Apr 14, 2020 at 2:16 PM Jere ***@***.***> wrote: @sttaft <https://github.com/sttaft> Thanks. I tried updating the proposal with how to handle it. I marked it as OPTIONAL. If it makes the proposal untenable, then it could easily be pulled back out and we could just consider them separate generic package specifications, but I would like to at least explore allowing them to be used interchangeably (with respect to the formal values supplied). I will say I am getting into a realm where I am not 100% good with the terminology so suggestions on how to fix any of it are appreciated. Hopefully it at least can be deciphered from the examples if I botched the wording. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANZ4FLVGKNQGWXAHEC7NMLRMSR6TANCNFSM4L7J3MFQ> .

[mosteo]

I have wanted so much this when working on my Rx and Iterators libraries.

About the extra level of indirection: this already happens sometimes with package renamings, so it's not an entirely new nuisance.

[briot]

I had missed that proposal, and saw it mentioned in https://github.com/AdaCore/ada-spark-rfcs/blob/topic/generic_instantiations/meta/rfc-improved-generic-instantiations.md

I also very much like this approach, and indeed missed it when working on the traits-containers library

[jere-software]

Thanks! I honestly thought this just got lost in the wind. Glad it can still poke its head around. Maybe one day we'll have something similar to it.