Re: Ada Component Registry proposal

["Jeff C," <nolongersafeto@userealemailsniff.com>]

"sk" <noname@myob.com> wrote in message
news:mailman.162.1066796252.25614.comp.lang.ada@ada-france.org...
> "Robert I. Eachus" <rieachus@comcast.net>:
>  > What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>  >
>  > The differences between some of these versions, and others not
>  > mentioned is slight. (For example, there were three differences
>  > between MIL-STD ...
>
> Interesting, I must look at my LRM (after I find it) to see whether I
> followed MIL-STD or ANSI/MIL-STD Ada'83 :-) This also might explain a
> recent problem of ARM quoting where myself and another where quoting
> from the same textual section/paragraph but were using different chapter
> numbers. However, I don't see this as particularly limiting.
>
> Another reason I would prefer a short and complete name, such as Ada95
> is that "CAL", "SAL", "XAL", "EACHUS" etc. don't suggest what they are
> and they are acronyms or peoples personal labels rather than being
> descriptive etc.
>
>  > I'm not trying to be a stickler for accuracy here, just pointing out
>  > that the Ada standard is evolving.  I'd hate to have the CAL come out
>  > labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
>
> Yes, but the inventory would be for *now* which is for Ada95 and prior,
> when sub-packages become suitable for Ada0x, then they move to the Ada0x
> tree. Not picking, just do not see the difficulty.

I think this is not the right path. When Ada 2020 comes out and we want to
add a new
subprogram to Ada05.Directory_Operations does that mean we now have an
Ada20.Directory_Operations
that looks the same but with the new procedure or do we add to it. No matter
what the answer is I don't think I
like it.