Ada Edition versioning of entities

[ARG-Editor]

This issue continues an unfinished issue from Ada 2022 (in this case, AI12-0018-1). This issue
was created to fulfill the ARG resolution of November 10, 2022.

Each edition of the Ada standard adds new entities, sometimes to existing
Ada packages. When creating portable programs, users want to be able to avoid
use of newer entities in their program (in order to use the program on the maximum
number of compilers).

Most Ada implementations provide some mechanism for determining the edition of Ada that
is being supported. Ironically, these mechanisms themselves pose a portability problem,
since everyone's is different.

Ada 2012 includes a set of restrictions for implementation-defined entities, but these
are limited to various places where the Ada language specifically allows
implementation-defined variations. In particular, compilation units defined outside of
the language-defined hierarchies are not included. For instance, package GNAT for the
GNAT implementation is not covered by the language-defined restriction, nor are the
many packages still retained for Ada 83 compatibility in implementations that existed
for Ada 83.

AI12-0018-1 proposes an aspect to specify the edition of code (including of user-defined
code) and series of restrictions to select sets of that code.

[ARG-Editor]

My thoughts on this issue:

The original proposal was left unfinished in part because standards are replaced, not additive. Therefore, we cannot talk about previous editions of the standard within the wording of the current standard.

That problem can be worked around by explicitly giving the values of the aspect in each unit defined in the language definition (rather than just saying that they apply to the entities first defined in that edition). That's clearly more work, but it is a one-time
expense (since those edition aspects never change). One also would need to add the aspect to the handful of routines added in later editions (such as those added into the Ada.Strings family).

Note that defining an identifier like Ada_2005 is acceptable, so long as we don't use a reference to the previous version of the standard. It should be fine to define an Ada_2005 identifier and apply it to the packages and subprograms added in Ada 2005.

There also was some confusion about the difference between Implementation_Defined and Third_Party_Defined entities. Some libraries are provided with compilers but are independent from those compilers; those sorts of reusable units should be identified as Third_Party_Defined. For instance, Claw is provided with some versions of Janus/Ada, but it is available for other compilers as well as Janus/Ada. So it is best identified as a Third_Party_Defined library. That would be the case for any reusable code intended for use with multiple compilers and/or projects. The actual owner of the library does not matter. (Perhaps there is a better name for this concept?)

An implementation of the AI12-0018-1 proposal exists. The Janus/Ada compiler implements this mechanism to provide versioning capabilities. (It doesn't implement the restriction pragmas at this time (or any restriction pragmas), but it does support similar compiler options and a full set of warnings.) All of the supported Ada language-defined units were annotated with this aspect, including all of the individual added subprograms in packages like Ada.Strings.Fixed.

The original proposal in AI12-0018-1 needs to replace Ada_2020 with Ada_2022, but of course that is a trivial change. Note that the restriction No_Implementation_Defined_Entities is slightly broader than the existing restrictions, since it includes top-level packages like GNAT for the Gnat implementation.

The main remaining question is whether Ada users would find the restrictions pragmas valuable enough to properly define these as part of the Standard. We're posting this as an issue in part to get some feedback on that.

             Randy.

[jprosen]

In the title: versioing => versioning

[sttaft]

This issue should be re-opened. Not sure why or how JP closed it.

[jprosen]

Because I clicked the wrong button and did not find how to undo it... Le 26/05/2023 à 13:28, S. Tucker Taft a écrit :

This issue should be re-opened. Not sure why JP closed it. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJBLSB26TXYFMZSAUONIXLXICHU3ANCNFSM6AAAAAAYPS4MGI>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX https://www.adalog.fr https://www.adacontrol.fr

[sttaft]

It is annoyingly easy to click the "comment and close" button. I also do not know how to repoen an issue. @Richard-Wai or @ARG-Editor?

[Richard-Wai]

Actually the same button used to "comment and close" should turn into "Reopen with comment", as I will do thusly.

[sttaft]

Interesting. I didn't get that. I also am not identified as a "collaborator", whereas Randy is. Could you invite me (@sttaft) to be a collaborator for this website?

And by the way, can only the author edit the title of an issue, or can any "collaborator" fix it? The title still needs fixing ...

Thanks,
-Tuck

[Richard-Wai]

Actually @sttaft I had invited you two before but it never seemed to go through.. I have just sent it through again, let me know if you see anything!

[ARG-Editor]

J-P wrote:\

In the title: versioing => versioning

I had saw that, but didn't see how to fix it. Looking at it now, I see an "edit" button next to the title, and pushing that let me fix the title. I see I can fix the spelling errors in the original post that way, too. Cool. :-)