Version 1.1 of acs/ac-00128.txt

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

!standard 13.3(75/1)          06-03-15 AC95-00128/01
!class confirmation 06-03-15
!status received no action 06-03-15
!status received 06-01-25
!subject External Tags

From: John Barnes
Date: Wednesday, January 25, 2006  1:43 AM

When rewriting my book, I decided to do an examle using the generic
dispatching constructor.  Following a suggestion from Pascal, I specifed the
external tags of a groupof related types thus

for Circle'External_Tag use "Circle";
for Triangle'External_Tag use "Triangle";
for Square'External_Tag use "Square";

The types Circle, Triangle and Square are all derived from

type Geometry is abstract tagged null record;

The question is suppose I give two types the same external tag.

What happens? It seems that this is unknown.

What should happen?  Do we want a BI?  Should the UK Head of Delegation make
an official comment on the draft?

What do you think?  Time is running out.

----- Original Message -----
From: "Randy Brukardt"
To: "John Barnes"
Sent: Tuesday, January 24, 2006 8:27 PM
Subject: RE: External tags

> John writes:
> > You may recall that you suggested that I write
> >
> > for Circle'External_Tag use "Circle";
> >
> > for Triangle'External_Tag use "Triangle";
> >
> > when fooling about with some geometry in my book.
> >
> > What happens if I give two types the same string? Do I get Tag_Error? Or
> > does it fail to compile? I note that the strings have to be
> > static. I can't find a reference to this in the AARM.
> I think you have a mess. :-)
> I would expect Internal_Tag and Dependent_Tag to return one of the tags, and
> the other would sort of disappear. Not the best result!
> I think you could make an argument for Tag_Error on the clause (requiring a
> post-compilation check seems like quite a burden on implementations) because
> this situation is certainly a mistake, but such a check would require a BI
> (there certainly is no such check now). [And certainly a post-compilation
> check would require a BI.] So I'd suggest asking the question on the full
> ARG list to see what others think.


From: Pascal Leroy
Date: Wednesday, January 25, 2006  3:35 AM

This seems like a nice topic for an Ada 2005 AI, but I would prefer if the
UK refrained from an official comment.  After all this cannot be a
pressing issue since it has been around for 11 years.

We have to be very cautious here.  It is not clear that disallowing this
situation (either through a check or through a post-compilation rule) is a
good idea.  Think of a recursive routine that declares a tagged type and
specifies its external tag:

	procedure P is
	   type T is tagged ...;
	   for T'External_Tag use "...";

As far as I can tell this code might work just fine: after all the various
incarnations of type T all have the same properties in terms of layout,
streaming, etc., so it's no big deal that they all have the same external
tag since they are essentially indistinguishable once written to a binary

I guess I am saying that the risk of introducing incompatibilities worries
me more than the (very minor) safety issue that arises if you associate
two unrelated types with the same external tag.  If you do that, it seems
that the very first test that you'll run will uncover the error.


From: Robert Dewar
Date: Wednesday, January 25, 2006  7:15 AM

or write a value out and read it back into the wrong type, or
give the same external name to two procedures or or or ...
Seems not worth worrying about to me. At most I would just
add a statement that the effect of doing this is impl defined.


From: Pascal Leroy
Date: Thursday, January 26, 2006  2:56 AM

My preference would actually be to make it _unspecified_.  I don't think
we want to force implementers to describe the external-to-internal tag
mapping mechanisms that they use (which can be fairly complicated, in
particular in the presence of nested type extensions), and I don't think
that we want to encourage users to depend on the details of these
mechanisms.  The message here is "don't do that, you won't like the


From: Robert Dewar
Date: Thursday, January 26, 2006  3:21 AM

Sounds fine to me (documentation requirements are always
bogus in my book anyway :-)


Editor's note: Since the behavior is not specified, it is hardly necessary
to add wording to repeat that. Thus this thread is filed here.


Questions? Ask the ACAA Technical Agent