CVS difference for ais/ai-00251.txt

Differences between 1.23 and version 1.24
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2004/07/27 23:00:49	1.23
+++ ais/ai-00251.txt	2004/09/04 01:13:42	1.24
@@ -5217,3 +5217,163 @@
 
 ****************************************************************
 
+From: Stephen W. Baird
+Sent: Tuesday, August 31, 2004  3:25 PM
+
+As an action item from the Palma meeting, I was asked to examine
+the interactions between AI-251 (interface types) and user-specified
+tag placement.
+
+Given an object of type My_Interface_Type'Class as the controlling operand
+in a dispatching call, the implementation must be able to locate the
+tag component in order to access the dispatch table. All implementation models
+that have been seriously discussed require that an interface type and a type
+which implements that interface agree with respect to (statically known) tag
+placement, typically at the very beginning of the record.
+
+13.5.1 states
+    An implementation may allow such implementation-defined names to be used
+    in record_representation_clauses. An implementation can restrict such
+    component_clauses in any manner it sees fit.
+
+The problem is that this does not permit imposing other restrictions once
+a component_clause has been accepted. For example, if two tagged types
+are successfully compiled with different user-specified tag placements, then
+it is not ok to reject some subsequent compilation_unit when an attempt is
+made to have descendants of these two types both implement some interface type.
+
+An implementation certainly has the option of simply requiring that the
+tag component must always reside, for example, at the start of the record.
+One way to accomplish this would be to provide no mechanism to allow the
+user to specify otherwise.
+
+This incompatible restriction is likely to displease an existing Ada95 user
+who is placing tags at some non-standard location (assuming her vendor
+provides some mechanism to do this), wants to migrate to Ada05,
+and has no intention of using Interface types.
+
+A second approach would be to allow implementations to require some sort
+of implementation-defined "representational compatibility" between an
+interface type and a type which implements the interface. This would
+probably require an inordinately large amount of very murky RM verbiage.
+
+This approach would have the (arguably insignificant) advantage of allowing
+the user to define a gaggle of tagged types (both interface and not)
+that all have their tags at the same non-standard offset and those types
+would all be compatible with each other with respect to this requirement.
+
+As a third approach, I suggest some sort of pragma, probably a restriction
+pragma, which promises that a given non-derived tagged type and all of its
+descendants will never be used to implement any interface.
+All violations would be rejected at compile-time.
+
+Vendors could then require this pragma as a prerequisite for nonconfirming
+user-specified tag placement.
+
+It would be even more convenient if user-specified tag placement could be
+viewed as also implicitly specifying this restriction, but I don't think
+this is currently permitted by the language.
+
+If only a small number of vendors support user-specified tag placement to
+begin with, and if this is the only known use for this restriction, then
+perhaps this pragma should be implementation-defined, not language-defined.
+
+IBM/Rational supports user-specified tag placement. Does anyone else?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August 31, 2004  5:41 PM
+
+Steve wrote:
+
+> As a third approach, I suggest some sort of pragma, probably a restriction
+> pragma, which promises that a given non-derived tagged type and all of its
+> descendants will never be used to implement any interface.
+> All violations would be rejected at compile-time.
+
+> Vendors could then require this pragma as a prerequisite for nonconfirming
+> user-specified tag placement.
+
+> It would be even more convenient if user-specified tag placement could be
+> viewed as also implicitly specifying this restriction, but I don't think
+> this is currently permitted by the language.
+
+This option would be preferable, I think. There wouldn't be any problem
+defining such a rule for the Standard.
+
+However, one implementer (lets call them "Rat" for short) has consistently
+opposed having legality rules depend on representation items. "Rat" killed
+AI-319 (Object_Size attribute) primarily for this reason. I'm sure that
+"Rat" would strongly oppose such a solution. (Removing tongue from cheek.)
+
+I think it would be a good idea to make a concrete proposal as to the form
+of the required pragma, so we can see what is being proposed. It's not clear
+to me what you have in mind; I would have thought that the pragma would
+apply only to the base type of a hierarchy, and I don't see how to make a
+restriction pragma that only applies to a single type. (A type name is not
+an expression.)
+
+>If only a small number of vendors support user-specified tag placement to
+>begin with, and if this is the only known use for this restriction, then
+>perhaps this pragma should be implementation-defined, not language-defined.
+
+>IBM/Rational supports user-specified tag placement. Does anyone else?
+
+Sigh. How soon they forget. :-)
+
+Janus/Ada does not have a way to name the tag component, but there is no
+restriction on its placement. It just goes into the first available DWord
+not used by a component placed by a representation clause.
+
+I would welcome a solution in the standard for this purpose; otherwise, we
+are taking a step backwards (as noted in Steve's note).
+
+****************************************************************
+
+From: Stephen W. Baird
+Sent: Friday, September 3, 2004  7:07 PM
+
+> I think it would be a good idea to make a concrete proposal as to the form
+> of the required pragma, so we can see what is being proposed. It's not clear
+> to me what you have in mind; I would have thought that the pragma would
+> apply only to the base type of a hierarchy,
+
+... I did say "non-derived" ...
+
+> and I don't see how to make a
+> restriction pragma that only applies to a single type. (A type name is not
+> an expression.)
+>
+
+That's a good point. I'd forgotten that a Restrictions pragma can't apply
+to a type. I suppose an entirely new representation pragma would be needed.
+Yuck.
+
+I haven't been able to come up with a reasonable name for this beast. This
+is a bad sign.
+
+I'm starting to think that the right approach might be to append something
+to 13.5.1(15) along the lines of
+     "Such representation clauses may affect the values of
+      implementation-defined aspects of representation."
+
+and then add an implementation permission section to 3.9.4 (see AI-251)
+something like
+     "An implementation may require that a descendant of an Interface type
+      and the Interface type shall be compatible with respect to
+      implementation-defined aspects of representation."
+
+and perhaps an AARM note explaining what this is really all about. It would
+need to be clearly stated that this should not be interpreted to mean that
+implementations have the freedom to arbitrarily reject derivations from
+interface types (e.g. because of an incompatibility in the "initial character
+of identifier" aspect of representation).
+
+Still, this seems preferable to adding a whole new section to the manual
+along the lines of C.5 (Discard_Names) or 13.2 (Pack).
+
+Comments?
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent