CVS difference for ais/ai-00263.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00263.txt

--- ais/ai-00263.txt	2001/05/26 02:55:11	1.4
+++ ais/ai-00263.txt	2001/06/02 04:13:15	1.5
@@ -190,3 +190,113 @@
 
 ****************************************************************
 
+From: Steve Baird
+Sent: Thursday, May 31, 2001  12:20 PM
+
+At the last ARG meeting, there was general agreement that the phrase "formal
+scalar type" in the second sentence of 4.9(26) should be replaced with
+"formal type".
+
+The analogous question for static string subtypes was not resolved.
+
+It was observed that the two cases of a formal array type and a
+formal derived array type ought to be treated consistently, but it was not
+obvious whether they both should be defined to be static or non-static.
+
+For example, either both or neither of the following two named number
+declarations should be legal:
+
+    type T is array (Character) of Character;
+
+    generic
+      type Ft1 is array (Character) of Character;
+      type Ft2 is new T;
+    package G is
+      Length_1 : constant := Ft1'Length;
+      Length_2 : constant := Ft2'Length;
+    end G;
+
+It was suggested that that broadening the definition of a static string subtype
+rather than narrowing it would not cause problems because the matching rules
+(12.5.1(8), 12.5.3(6)) would ensure that the FIRST, LAST, and LENGTH
+attributes of the actual subtypes would match those of the formal.
+
+This appears to be true, but there may still be reasons for restricting the
+definition. A string literal of a static string subtype is a static expression.
+Would it pose difficulties for a shared code generic implementation if the
+representation of a static expression varied among instantiations? This could
+occur if the actual types were subject to different representation
+specifications.
+
+For example:
+
+    package Foo is
+      subtype Index is Integer range 1 .. 3;
+
+      type T is array (Index) of Character;
+      for T'Component_Size use Character'Size;
+
+      generic
+        type Ft1 is array (Index) of Character;
+        type Ft2 is new T;
+      package G is
+        Lit1 : constant Ft1 := "123";
+        Lit2 : constant Ft2 := "123";
+      end G;
+
+      type D is new T;
+      for D'Component_Size use 2 * Character'Size;
+
+      package I1 is new G (T, T);
+      package I2 is new G (D, D);
+    end Foo;
+
+My guess is that this is not a problem.
+
+Another argument for the more restrictive definition is
+consistency with the scalar case.
+
+I don't think these arguments are persuasive; I suggest that
+the definition of static string subtype be broadened by deleting the text
+  "(and whose type is not a descendant of a formal array type)"
+from 4.9(26).
+
+Comments?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 1, 2001  7:40 PM
+
+Sigh. These gung-ho new members; they don't even let us catch our breath. :-)
+
+> This appears to be true, but there may still be reasons
+> for restricting the definition. A string literal of a
+> static string subtype is a static expression. Would it pose
+> difficulties for a shared code generic implementation if
+> the representation of a static expression varied among
+> instantiations? This could occur if the actual types
+> were subject to different representation specifications.
+> ...
+> My guess is that this is not a problem.
+
+I don't think the representations is a problem. Any string literal can have
+different representations. Janus/Ada generates these things at runtime. I don't
+think that the fact that they are defined to be static makes any difference.
+
+Janus/Ada has no problem compiling the above program; I don't think that the
+staticness (or lack of it) matters in this example. It would be more interesting
+if the constants were then used in a pragma Import, but again, the
+representation of the static expression isn't necessarily the same as that of
+the runtime object, so there isn't any problem.
+
+> I don't think these arguments are persuasive; I suggest that
+> the definition of static string subtype be broadened by deleting the text
+>   "(and whose type is not a descendant of a formal array type)"
+> from 4.9(26).
+
+Seems OK to me. Assuming that static strings can't be used in a context where
+the component representation matters (which I believe to be the case).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent