Restrictions and Profiles

[CKWG]

I propose to add two new RM subclauses named L.1 Language Defined Restrictions and L.2 Language Defined Profiles,

I know there is 13.12.1 1 Language Defined Restrictions and Profiles, but this does not name all identifiers.

The index lists all restrictions and profiles, but it is cumbersome to use. Seaching for "Profiles" gives no hit at all if you restrict the search to case sensitive; "Profile" gives four hits just for the pragma.

Search for "profiles" gives one hit which is not what you want. Search for "profile" gives you 18 hits, mostly for parameter profiles, which is not what you want. There is one hit with "profile" as the main entry with a list, one of these list elements is "No_Implementation_Extensions"; you don't get Jorvik nor Ravenscar with this search.

Search for "restriction" on the other hand gives 65 hits all over the index. Search for "restrictions" finally gives you one hit with a list of all language defined restriction.

The subclauses proposed would fulfil the need.

[ARG-Editor]

The index is your friend. What you want can be found there. If you look up "restrictions" in the index, you will find a listing of all of the restrictions, and the places that they are defined. Profiles are not indexed that way, but they should be. I've added a note to AI22-0005-1 to fix that in the next version of the RM (there are a number of other things that we want to add indexing for, for instance, the places that static expressions are required - indexing is much easier to maintain than an AARM note somewhere that tends not to be updated when something changes in the language).

It would be possible to create an annex as you suggest, but that would require writing one line descriptions for all of the restrictions and profiles. We'd need a volunteer to do that (there's too many to just dump it on the editor).

[CKWG]

If you look up "restrictions" in the index, you will find a listing of all of the restrictions, and the places that they are defined. This is what I wrote. Profiles are not indexed that way This is about what I wrote. I think the proposed subclauses are just on the level of usefulness as K to K.2 and L. All this can be found in the index, nevertheless the subclauses were found important enough to be created.

Now I would volunteer to provide an attempt for L.1 and L.2, but the question is: In what format? I had thought these annexes are automatially created form the raw RM itself, just like the index. If this is not the case, who adapts K1. and K.2 and L (and propsed L.1 and L.2) to changes in the next Ada generation, lest they might get out of synch? I know they are not normative, but...

[CKWG]

Sht. The closing was a mistake.

[CKWG]

As an example of how such appendices are created, I looked into the RM source code for Appendix K and found an AttriibuteList which seems to be automatically created, but in RM 3.10.2 for attribute Access, I found no reference to AttributeList. So I have no clue how such a list is created.

[ARG-Editor]

(1) The documentation of the formatter is your friend. Look for Command.Txt in a copy of the source of the formatter, or on-line.

(2) The way attributes are handled is very messy (it was inherited from Ada 95), it's a lousy example. I'd suggest looking at the aspect list instead.

A generic description is that there is generally one or more commands for defining individual entries (@ChgAspectDesc). These are put into a "database" (really, just a set of tuples). And there is a command for generating the result (@AddedAspectList) which sorts and outputs the list appropriately.

To add a new kind of list, one needs to define new commands for each task (defining items, and outputting the result). It should be possible to implement them on top of the existing "database" implementation (which has the needed formatting and sorting).

The major job is defining the tuples, with a short description of each thing:

Profile No_Stupid_Features -- prevents the use of stupid features of Ada like coextensions and anonymous access types.

[This is not a real profile!!]

And similarly for all of the restrictions. The trick is to keep the descriptions short and clear. (We probably don't always succeed on either count, but we try).

                              Randy.