Version 1.1 of acs/ac-00212.txt

Unformatted version of acs/ac-00212.txt version 1.1
Other versions for file acs/ac-00212.txt

!standard A.18(00)          11-01-28 AC95-00212/01
!class Amendment 11-01-28
!status received no action 11-01-28
!status received 10-12-01
!subject Organization of Clause A.18
!summary
!appendix

I'm a bit worried about changing *(sub)chapter* numbers. Until now, from one Ada
generation to the next, at most the *paragraph* numbers changed, perhaps also
(sub)chapter titles, but their numbers didn't change, so that references like RM
ss.ss stayed correct.

With the new 2012 generation, most of the references to A.18.ss become wrong. I
would like to suggest a new numbering scheme, which also changes the numbers
now, but is able to keep them in future. This scheme will however have four
levels.

This is the current 2005 versus 2012 numbering:
2005       2012
A.18              Containers
A.18.1            The Package Containers
A.18.2            The {Generic} Package Containers.Vectors
A.18.3            The {Generic} Package Containers.Doubly_Linked_Lists
A.18.4            Maps
A.18.5            The {Generic} Package Containers.Hashed_Maps
A.18.6            The {Generic} Package Containers.Ordered_Maps
A.18.7            Sets
A.18.8            The {Generic} Package Containers.Hashed_Sets
A.18.9            The {Generic} Package Containers.Ordered_Sets
         A.18.10  The Generic Package Containers.Multiway_Trees
A.18.10  A.18.11  The {Generic} Package Containers.Indefinite_Vectors
A.18.11  A.18.12  The {Generic} Package Containers.Indefinite_Doubly_Linked_Lists
A.18.12  A.18.13  The {Generic} Package Containers.Indefinite_Hashed_Maps
A.18.13  A.18.14  The {Generic} Package Containers.Indefinite_Ordered_Maps
A.18.14  A.18.15  The {Generic} Package Containers.Indefinite_Hashed_Sets
A.18.15  A.18.16  The {Generic} Package Containers.Indefinite_Ordered_Sets
         A.18.17  The Generic Package Containers.Indefinite_Multiway_Trees
         A.18.18  The Generic Package Containers.Indefinite_Holders
         A.18.19  The Generic Package Containers.Bounded_Vectors
         A.18.20  The Generic Package Containers.Bounded_Doubly_Linked_Lists
         A.18.21  The Generic Package Containers.Bounded_Hashed_Maps
         A.18.22  The Generic Package Containers.Bounded_Ordered_Maps
         A.18.23  The Generic Package Containers.Bounded_Hashed_Sets
         A.18.24  The Generic Package Containers.Bounded_Ordered_Sets
         A.18.25  The Generic Package Containers.Bounded_Multiway_Trees
A.18.16  A.18.26  Array Sorting
         A.18.27  The Generic Package Containers.Synchronized_Queue_Interfaces
         A.18.28  The Generic Package Containers.Unbounded_Synchronized_Queues
         A.18.29  The Generic Package Containers.Bounded_Synchronized_Queues
         A.18.30  The Generic Package Containers.Unbounded_Priority_Queues
         A.18.31  The Generic Package Containers.Bounded_Priority_Queues
         A.18.32  Indefinite Synchronized Queues

Proposal

A.18      Containers
A.18.1    The Package Containers
A.18.2    Vectors
A.18.2.1  The Generic Package Containers.Vectors
A.18.2.2  The Generic Package Containers.Indefinite_Vectors
A.18.2.3  The Generic Package Containers.Bounded_Vectors
A.18.3    Lists
A.18.3.1  The Generic Package Containers.Doubly_Linked_Lists
A.18.3.2  The Generic Package Containers.Indefinite_Doubly_Linked_Lists
A.18.3.3  The Generic Package Containers.Bounded_Doubly_Linked_Lists
A.18.4    Maps
A.18.4.1  The Generic Package Containers.Hashed_Maps
A.18.4.2  The Generic Package Containers.Ordered_Maps
A.18.4.3  The Generic Package Containers.Indefinite_Hashed_Maps
A.18.4.4  The Generic Package Containers.Indefinite_Ordered_Maps
A.18.4.5  The Generic Package Containers.Bounded_Hashed_Maps
A.18.4.6  The Generic Package Containers.Bounded_Ordered_Maps
A.18.5    Sets
A.18.5.1  The Generic Package Containers.Hashed_Sets
A.18.5.2  The Generic Package Containers.Ordered_Sets
A.18.5.3  The Generic Package Containers.Indefinite_Hashed_Sets
A.18.5.4  The Generic Package Containers.Indefinite_Ordered_Sets
A.18.5.5  The Generic Package Containers.Bounded_Hashed_Sets
A.18.5.6  The Generic Package Containers.Bounded_Ordered_Sets
A.18.6    Trees
A.18.6.1  The Generic Package Containers.Multiway_Trees
A.18.6.2  The Generic Package Containers.Indefinite_Multiway_Trees
A.18.6.3  The Generic Package Containers.Bounded_Multiway_Trees
A.18.7    The Generic Package Containers.Indefinite_Holders
A.18.8    Array Sorting
A.18.9    Queues
A.18.9.1  The Generic Package Containers.Synchronized_Queue_Interfaces
A.18.9.2  The Generic Package Containers.Unbounded_Synchronized_Queues
A.18.9.3  The Generic Package Containers.Bounded_Synchronized_Queues
A.18.9.4  The Generic Package Containers.Unbounded_Priority_Queues
A.18.9.5  The Generic Package Containers.Bounded_Priority_Queues
A.18.9.6  Indefinite Synchronized Queues

***************************************************************

From: Randy Brukardt
Sent: Friday, January 28, 2011  10:42 PM

> I'm a bit worried about changing *(sub)chapter* numbers.
> Until now, from one Ada generation to the next, at most the
> *paragraph* numbers changed, perhaps also (sub)chapter titles, but
> their numbers didn't change, so that references like RM ss.ss stayed
> correct.

That's not quite accurate. Ada 2005 did change a couple of section numbers; all
of them were non-normative material however. Similarly, there are a number of
cases where we decided to allow notes and examples to change paragraph numbers
without any marking, in order to avoid large swaths of inserted paragraphs.

> With the new 2012 generation, most of the references to A.18.ss become
> wrong.

This was done after careful consideration of the alternatives, including the
original suggestion (of leaving all of the numbers unchanged), various orders
that only changed the position of A.18.16, and adding an extra level. The
feeling was that references to paragraph numbers of the predefined packages is
much lower than that of the language core; in particular, such references don't
show up in compilers or related tools. Most references to the predefined
packages reference the entire package, which isn't that hard to find in any
case.

> I would like to suggest a new numbering scheme, which also changes the
> numbers now, but is able to keep them in future. This scheme will
> however have four levels.

Adding a level could be damaging for existing Ada tools, which may have schemes of paragraph reference which could not handle an extra level without a lot of retrofiting. Janus/Ada, for instance, represents RM references as a record:
    (Version, Chapter, Clause, Subclause, Paragraph Number, Count) which is
packed into 32-bits. There is an aggregate of this record type associated with
most compiler error message within the compiler. Changing all of those
aggregates (and remember that Ada has no such thing as a default component in an
aggregate, it has to be given explicitly) would be a major pain, and the result
would no longer fit into 32-bits, forcing an increase in the error message
descriptor size.

Similarly, references that are just fixed length strings would be a problem, as
the maximum string length would be longer. For instance, we already have
"A.18.2(239.2/3)" as a paragraph reference. If the paragraph references have a
maximum of 15 characters (which would handle all known references), there is a
problem if this gets changed to "A.18.2.1(239.2/3)" as in your proposal
(17-characters). This is fairly likely in Ada code, as fixed strings are much
easier to deal with than variable lengthed ones. (Of course, whether this is
easy to change or not depends on how it is used.)

None of this is particularly compelling, of course. But neither is any other
organization that has been proposed.

As far as the future is concerned, there is no way to tell. If ISO ever decided
to require us to follow the drafting requirements for standards, pretty much the
entire standard would have to be renumbered -- we do a lot of things that are
not allowed. Your proposed reorganization doesn't help that any (for instance,
all of the "parent" clauses have to be empty) - indeed it probably makes it
worse by effectively requiring the entire containers clause to be in fourth
level sections.

The answer is there is no good answer, only a lot of bad ones. The one we have
is just as good (or bad) as any other choice.

***************************************************************

Questions? Ask the ACAA Technical Agent