CVS difference for ai05s/ai05-0003-1.txt

--- ai05s/ai05-0003-1.txt	2007/08/07 01:16:16	1.2
+++ ai05s/ai05-0003-1.txt	2007/10/31 02:24:49	1.3
@@ -1,5 +1,9 @@
-!standard  4.1(2)                                    06-03-15    AI05-0003-1/01
-!standard  4.7(0)
+!standard  3.3(11)                                   07-10-29    AI05-0003-1/02
+!standard  3.3(21)
+!standard  4.1(2)
+!standard  4.4(7)
+!standard  4.7(3)
+!standard  5.4(7)
 !class Amendment 05-10-24
 !status work item 06-03-15
 !status received 05-09-20
@@ -28,21 +32,122 @@
 
 !proposal
 
-One option is to keep "name" as is, but make
-"prefix" more flexible. We're not looking to
-allow more things on the LHS of an assignment or as an OUT
-parameter.  Mostly we want to be able to use <blah>.component
-or <blah>(index) or <blah>.all, without getting slapped
-on the wrist because <blah> is not "officially" a "name."
+Treat qualified_expressions as names rather than as expressions.
+A qualified_expression is never considered a variable, however.
 
 !wording
 
+Add after 3.3(11):
+
+  * a qualified_expression whose operand denotes an object;
+
+Add after 3.3(21):
+
+  * the result of evaluating a qualified_expression;
+    
+Modify 4.1(2) to add "| qualified_expression" somewhere
+
+Modify 4.4(7) to remove "| qualified_expression"
+
+Add a new paragraph after 4.7(3):
+
+                 Static Semantics
+      
+   If the operand of a qualified_expression denotes an object, the
+   qualified_expression denotes a constant view of that object.  The
+   nominal subtype of a qualified_expression is the subtype denoted by
+   the subtype_mark.
+   
+Change 5.4(7) as follows:
+
+   If the expression is a name [Redundant: (including a
+   type_conversion{, a qualified_expression,} or a function_call)]
+   having a static and constrained nominal subtype, [or is a
+   qualified_expression whose subtype_mark denotes a static and
+   constrained scalar subtype,] then each non-others discrete_choice
+   shall cover only values in that subtype, and each value of that
+   subtype shall be covered by some discrete_choice [Redundant:
+   (either explicitly or by others)].
+   
 !discussion
 
+We propose to allow qualified_expressions anywhere names are allowed
+(syntactically).  The main purpose is to allow them as a prefix, but
+there seems no harm in allowing them more generally, in particular
+before ".all". 
+
+We do not consider a qualified_expression to be a variable, even if
+its operand denotes a variable.  The added complexity of allowing
+certain qualified_expressions on the left-hand side of an assignment
+or as an [IN] OUT parameter does not seem to be justified.  We
+considered allowing qualified_expressions whose operands denote
+variable objects of a *tagged* type to be variables (analogous to the
+rule for type_conversion), but it added complexity, without any
+obvious benefit.  Ambiguity generally involves calls on overloaded
+functions, and the result of a function call is always a constant, so
+it is not clear there are enough ambiguous names of variables to even
+worry about.
+
+One kind of overloaded variable name is "overloaded_function.all", but
+in that case, we would now allow "T'(overloaded_function).all"
+so there is no need to apply the qualification to the dereference
+as a whole, just to the pointer.
+
+For an assignment statement to be ambiguous, both the left-hand
+side and the right-hand side would need to be overloaded, in
+which case the qualified_expression could be applied to the
+right-hand side rather than the left-hand side, again avoiding
+the need to have qualified_expressions that are variables.
+
+We had considered defining a separate "qualified_name" construct
+which would require that the operand be a name, for the qualified
+construct to be considered a name.  This was to prevent certain 
+uses like:
+
+   T'(A => 3, X => 4).X
+ or
+   Str'("this is fun")'Length
+
+But these are already allowed by simply wrapping them
+in an identity conversion, such as:
+
+   T(T'(A => 3, X => 4)).X
+ or
+   Str(Str'("this is fun"))'Length
+ 
+so it is hard to imagine that there is any significant
+implementation or cognitive burden to allowing them directly.
+
+Of course the main *intent* is to allow calls on overloaded 
+functions to be qualified as necessary to eliminate ambiguity,
+without losing the ability to use them in contexts
+requiring names.  But there also seems no justification in
+creating more complicated syntax rules just to prevent other kinds
+of qualified_expression usages that are effectively already 
+possible in a somewhat uglier form.
+
+We add the definition of the nominal subtype of a qualified_expression,
+since there is an assumption that names always have nominal subtypes
+(in particular, in the rules for case statements -- also see AI05-0006).
+
+We define a qualified_expression of an object to be a constant
+view of that same object so that attributes like 'Address are 
+well defined.
+
 !example
 
+    Foo(Ptr'(Overloaded_Function_Returning_Ptr).all);
+    
+    Rec_Ptr'(Overloaded_Function_Returning_Rec_Ptr).X := Y;
+    
+    Z := Arr_Ptr'(Overloaded_Function_Returning_Arr_Ptr)(J);
+    
+    L := Arr_Ptr'(Overloaded_Function_Returning_Arr_Ptr)'Length;
+    
+    
 !ACATS test
 
+
 !appendix
 
 !topic Qualified expressions and "names"
@@ -120,5 +225,42 @@
     Val : Integer renames "+"(A, 3); -- Legal
 
 See AC-00143 for a thread about this problem and its effects.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, October 29, 2007 4:55 PM
+
+Here is my other "low priority" AI [version /02 - ED], about
+allowing qualified_expressions where names
+are allowed.  I tried various approaches, but
+ultimately ended up with the simplest, which
+is basically just to move qualified_expression
+in the grammar from "expression" to "name."
+
+I considered only allowing them as prefixes,
+but that didn't allow "T'(overloaded).all" which
+seems pretty useful.  I also considered creating
+a separate "qualified_name" construct, which was
+a qualified_expression whose operand was a name,
+but that didn't seem to buy much.  I think the
+goal was to prevent things like Str'("this is a string")
+from being names, but it turns out you can make
+pretty much anything into a name by wrapping it
+in an identity conversion:
+
+    Str(Str'("this is a string"))
+
+so it didn't seem worth sweating hard disallowing
+such things.
+
+The other thing I did was make qualified_expressions
+constants, even if their operand was a variable.
+I toyed with other rules, e.g. allowing tagged
+variables to remain variable when qualified, but
+I couldn't find compelling examples where that
+would be useful.
+
+So have fun reading!
 
 ****************************************************************