Open jere-software opened 4 years ago
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?
@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.
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 notifications@github.com 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 https://github.com/AdaCore/ada-spark-rfcs/pull/41#issuecomment-613599703, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FLVGKNQGWXAHEC7NMLRMSR6TANCNFSM4L7J3MFQ .
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.
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
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.
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:
to be simplified (notionally) in a later generic:
using the syntax:
without needing to provide scaffolding or package chaining.