!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 !summary !appendix 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 "..."; begin ... P; ... end; 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 file. 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 results". **************************************************************** 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. ****************************************************************