Version 1.1 of ais/ai-00365.txt

Unformatted version of ais/ai-00365.txt version 1.1
Other versions for file ais/ai-00365.txt

!standard A(04)          03-12-04 AI95-00365/01
!standard A.2(04)
!class amendment 03-12-04
!status received 03-10-11
!priority Low
!difficulty Easy
!subject Permissions to create grandchildren of Ada
!summary
The language is just fine as it is.
!problem
It is not possible for users to portably create library units in the existing language-defined package hierarchies. That is because A(4) allows implementations to restrict the compilation of language-defined library units and their children. Thus, a conforming Ada implementation need not allow the compilation of any decendant of Ada, System, or Interfaces.
!proposal
None needed.
!wording
None needed.
!discussion
It generally is a bad idea to mix up user-defined code with language-defined and potentially implementation-defined items. This is only appropriate when performance issues demand the use of a child package. Otherwise, the use of a separate hierarchy is indicated.
Most existing implementations provide some mode which allows compilation of packages into the Ada hierarchy. This is good enough for the rare cases where performance concerns require add-ons to the standard packages.
!example
--!corrigendum
!ACATS test
!appendix

From: Robert I. Eachus
Sent: Saturday, October 11, 2003  12:58 PM

I'm not sure if this should be a separate AI, or part of one of the existing
revision AIs.  Right now RM A.2(4) is misleading.  The AARM points out some of
the issues, which is probably fine as far as implementors are concerned, and in
any case I don't see any real reason to change it right now.

But if we add an Ada.Containers, and some of the other proposed libraries to
Ada, we really need to rethink the issue of extending Ada.  Below is a post I
made on comp.lang.ada basically responding to someone who thought that, if an
Ada.Containers existed, it shouldn't be used because it might be difficult to
extend it.  Certainly I don't think anyone in the ARG wants that.

But Ada.Containers would be a slightly different case from the current
situations where compiler vendors are allowed/encouraged to extend packages in
Ada.  For an Ada.Container tree it would make perfect sense to allow users, not
just vendors, to extend (but not replace in standard mode) Ada.Containers.

So, for now, just think of this as a tickler file entry saying to review A.2(4)
when all the decisions on new children of Ada in Ada 200X are final.

---------------------------------------------------------------------------------
I said:

> By the way, the ARM A.2(4) says that: "In the standard mode, it is
> illegal to compile a child of package Ada."

> But don't take that to mean what it doesn't say.  The AARM adds a
> reason, a ramification, and an Implementation Note...

Marin David Condic said:

>Note that the ARM doesn't appear to say "Thou shalt provide a mode under
>which a common, ordinary, garden-variety user can extend and modify
>packages under Ada...". Hence there may not be. There may be no source
>delivered for things under Ada. There may be no method provided to
>recompile the source even if it is provided. The source may not even be
>in Ada - it could be in C or assembler or in Jovial for all that the
>standard has to say about it.

Um, yes, the ARM doesn't say that, and I like it that way.  But I do think the
paragraph I pointed to needs fixing, and I think that we will definitely end up
with an Ada.Containers hierarchy that vendors--and users--should be allowed to
extend.  There are a couple of places where vendors are currently encouraged to
add packages to Ada or modify the standard packages. It might be worthwhile to
pull all of those together in one place, as well as their current locations:

A.3.3(31): "An implementation may provide additional packages as children of
Ada.Characters, to declare names for the symbols of the local character set or
other character sets."

A.5.1(48): "The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type."

A.15(21): "An alternative declaration is allowed for package Command_Line if
different functionality is appropriate for the external execution environment."


Stephane Richard wrote:
> I think so, seems reasonable for me, but shouldn't it basically depend on
> the licence?  or would anything in there have the same licence?  or an
> OpenSource Based licence so to speak so that it is available?

I don't think that is an issue.  If the specifications are in the standard,
then providing an additional child package does not necessarily require knowing
the contents of the package body, or even, to some extent, the contents of the
private part of the package.

So I think we are okay leaving this undefined.  If a compiler vendor wants to
make it difficult for a user to extend a package defined in the standard, they
can.  But I don't expect the situation to come up.  Most "sensible" extensions
to Ada will be in places like Ada.Characters.XXX, Ada.Strings.XXX,
Ada.Numerics.XXX, etc.  These packages don't have a private part.

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

From: Randy Brukardt
Sent: Tuesday, October 28, 2003  4:28 PM

> I'm not sure if this should be a separate AI, or part of one of
> the existing revision AIs.  Right now RM A.2(4) is misleading.
> The AARM points out some of the issues, which is probably fine as
> far as implementors are concerned, and in any case I don't see
> any real reason to change it right now.

I don't get it. A.2(4) says "In the standard mode, it is illegal to compile
a child of package Ada." It doesn't say "descendant"; it's clearly legal for
a user to compile a grandchild of Ada (assuming it is not a language-defined
library, which could run afoul of A(4)).

Both GNAT and Janus/Ada provide implementation-defined children of
Ada.Text_IO, so this is already common practice.

> But if we add an Ada.Containers, and some of the other proposed
> libraries to Ada, we really need to rethink the issue of
> extending Ada.  Below is a post I made on comp.lang.ada basically
> responding to someone who thought that, if an Ada.Containers
> existed, it shouldn't be used because it might be difficult to
> extend it.  Certainly I don't think anyone in the ARG wants that.

Why would it be hard to extend it? Any extension would be a child of
Ada.Containers, and it is perfectly legal to compile that. Just as it is
legal to compile a child of Ada.Strings.

> But Ada.Containers would be a slightly different case from the
> current situations where compiler vendors are allowed/encouraged
> to extend packages in Ada.  For an Ada.Container tree it would
> make perfect sense to allow users, not just vendors, to extend
> (but not replace in standard mode) Ada.Containers.

It makes no more sense to extend Ada.Containers itself (which is just a
placeholder containing nothing but children and possibly a handful of
exception declarations) than it would to extend Ada.Strings. And this would
be an awful mess to describe and implement (how would you tell that a
package is an extension instead of a replacement?).

Indeed, if anything, A.2(4) is too weak, as it would allow the user to
replace large parts of valuable functionality (Ada.Strings.xxx,
Ada.Numerics.xxx, etc.) which really shouldn't be replaced. But, an
implementation can use A(4) to do that if it wishes, so there is no critical
problem here.

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

From: Robert Dewar
Sent: Tuesday, October 28, 2003  9:29 PM

> it's clearly legal for
> a user to compile a grandchild of Ada (assuming it is not a language-defined
> library, which could run afoul of A(4)).

No it is not "clearly legal", let's look at A(4)

> 4   The implementation may restrict the replacement of language-defined
> compilation units.  The implementation may restrict children of
> language-defined library units (other than Standard).

grandchildren of Ada are clearly children of language-defined library units
and it is fine for an implementation to prohibit their definition (GNAT
certainly does prohibit such children in standard mode).

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

From: Randy Brukardt
Sent: Wednesday, October 29, 2003  4:02 PM

We don't use that permission for that purpose (we use it only to restrict
replacement and children of 'built-in' units like Unchecked_Conversion and
System which don't have a separate existence), but you are certainly right
that you could.

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

From: Robert Dewar
Sent: Wednesday, October 29, 2003  7:04 PM

Fine, but certainly legal is not about implementation dependent behavior :-)

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

From: Robert I. Eachus
Sent: Wednesday, October 29, 2003  12:20 AM

Randy said:

> Why would it be hard to extend it? Any extension would be a child of
> Ada.Containers, and it is perfectly legal to compile that. Just as it is
> legal to compile a child of Ada.Strings.

I just sent a message to Dan Eilers saying that I was beginning to think that
AI-302 adding a set of container packages to Ada was beginning to look like a
bad idea.  My thought was that what the ARG should be doing, if anything, about
container libraries would be to make it easier for users to write container
libraries as generics with a "type Element (<>) is private;" (or limited
private) formal parameter.  (Ideas on request, but right now I am on a
different topic.)

But the idea of the ARG adding Ada.Containers to the Ada heirarchy and not
allowing users and compiler vendors to add additional instances would IMHO be
an abomination.  Trying to make a "one size fits all" set of containers is
tough, you end up with compromises.  But in the standard, we would be much
better off including a small number of containers with no compromises for their
indended purpose.  (In the notation that has become common, protected queues
and unprotected lists of limited components are probably the two most useful.
But again that is not the topic here.)

The problem is that there are specialized container types that are useful in
their place.  For example right now I am in the midst of implementing a
heterogenous queue and list.  There is no real reason why I have to have them
share Element types, it just allows me to "get away with" on generic
instantiation per Element type instead of two.  However the effort to cobble
this together out of existing container types is less hassle.

So why the problem?  If I distribute my containers I want users (or compiler
vendors) to be able put them with other container types.  If the ARG wants that
collection in Ada.Containers fine.  But if some of you want to put a fence
around it, I vote no.  Having one place to look for container types is
important.  There may be people very familiar with the GRACE naming style, and
so they know that they want a controlled_limited_deque or whatever.  But most
programmers (including me) need to look at what a particular package provides
as parameters and operations.

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

From: Randy Brukardt
Sent: Wednesday, October 29, 2003  4:18 PM

Fair enough. What I was confused by was that you put the wrong paragraph
reference in your comment. (The problem is A(4), as noted by Robert Dewar,
not A.2(4).)

OTOH, I completely disagree with your opinion. Mixing standard stuff with
random user junk can be very confusing. It is much better to keep user stuff
separate, so it is clear who is responsible for support. I certainly don't
want support calls on Ada.Containers.Eachus_Queues. Well organized
organizations probably ought to have a repository of reusable components
beyond those in the standard, and that ought to be kept clearly separate.
I'd prefer that Ada vendors keep their added stuff to a minimum (generally
just the packages suggested by the standard) as well. But I don't see much
evidence of abuse here, so that standard is good enough in this area.

In any case, A(4) puts this decision in the hands of your vendor. Since they
are going to be most affected by the decision (in terms of support costs and
possibly development effort), that seems fair. As I said, Janus/Ada doesn't
enforce such a restriction (mainly because it would be a lot of work). So
you could do what you want with our compiler (even though I think it is a
bad idea).

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

From: Robert I. Eachus
Sent: Thursday, October 30, 2003  12:37 AM

I don't think the position I was advocating is all that different from yours.
But maybe I didn't explain it too well.  If the opinion of most members of the
ARG is that users shouldn't be replacing or extending language defined
packages, that is fine with me.  In that case I will vote against any language
defined container library for the reasons stated.  But that does not mean I
will automatically vote for some library if users will be allowed to extend it.

This time around, I really think that the ARG should concentrate on whatever is
necessary to make good container libraries easy to implement in Ada.  Then in
five years maybe we will know which container packages do and do not belong in
the ARM.

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

Questions? Ask the ACAA Technical Agent