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

--- ai05s/ai05-0177-1.txt	2011/01/25 08:00:08	1.8
+++ ai05s/ai05-0177-1.txt	2011/01/31 04:37:12	1.9
@@ -90,7 +90,7 @@
 
 Modify the last sentence of 3.11.1(1/1):
 
-A body is a body, an entry_body, {a null_procedure_declaration or 
+A body is a body, an entry_body, {a null_procedure_declaration or
 expression_function_declaration that completes another declaration}, or a
 renaming-as-body (see 8.5.4).
 
@@ -106,7 +106,7 @@
 subprogram declared by a subprogram_declaration is not. See 3.9.3, “Abstract
 Types and Subprograms”. Similarly, a procedure {declared}[defined] by a
 null_procedure_declaration is a null procedure; a procedure declared by
-a subprogram_declaration is not. See 6.7, “Null Procedures”. 
+a subprogram_declaration is not. See 6.7, “Null Procedures”.
 {Finally, a function declared by an expression_function_declaration is an
 expression function; a function declared by a subprogram_declaration is not. See
 6.8, "Expression Functions".}
@@ -430,16 +430,16 @@
 
 Returns False for any other Element including Nil_Element.
 
-Element expects an element that has the following Element_Kinds: 
+Element expects an element that has the following Element_Kinds:
 A_Declaration
-that has one of the following Declaration_Kinds: 
+that has one of the following Declaration_Kinds:
 A_Function_Declaration
 A_Function_Body_Declaration
 
 Usage Note: This routine tests for the syntactic element expression_function_declaration;
 calling Is_Expression_Function on a renaming of an expression function will return False.
 Use the routine ASIS.Callable_Views.Is_Expression to determine if a declaration is semantically
-an expression function (including renames). 
+an expression function (including renames).
 
 Discussion: A generic function cannot be an expression function.
 
@@ -452,16 +452,16 @@
 
       Returns the expression in the expression function declaration.
 
-      Declaration expecrs an element that has the following Element_Kinds: 
+      Declaration expecrs an element that has the following Element_Kinds:
          A_Declaration
-         that has one of the following Declaration_Kinds: 
+         that has one of the following Declaration_Kinds:
             A_Function_Declaration
             A_Function_Body_Declaration
 
       Raises ASIS_Inappropriate_Element with a Status of Value_Error for any element
       that does not have these expected kinds.
 
-      Returns an element that the following Element_Kinds: 
+      Returns an element that the following Element_Kinds:
          An_Expression
 
 
@@ -5589,6 +5589,68 @@
 
 ****************************************************************
 
+From: Robert Dewar
+Date: Sunday, July 11, 2010  7:59 AM
+
+I just implemented this, as described, but it's a little delicate to distinguish between function bodies and parametrized expressions
+
+    function F (X : Integer) is Long_Identifier ,
+    function F (X : Integer) is Long_Identifier +
+
+Any time distinguishing things is tricky for the compiler, it points to two
+possible problems:
+
+   a) difficulty for humans reading the code
+
+   b) difficulty for compilers in handling error situations
+
+I am wondering wheter we should require the expression to be parenthesized to
+avoid any such near ambiguities.
+
+I don't feel strongly, just raising the issue to see how others feel, I am
+inclined to require the parens (like requiring them around conditional
+expressions).
+
+****************************************************************
+
+From: Tucker Taft
+Date: Sunday, July 11, 2010  9:19 PM
+
+Parentheses are already required by the proposal.
+Perhaps you were looking at an older version or simply missed the parens.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, July 11, 2010  9:25 PM
+
+OK, either way, that's definitely an improvement.
+It will simplify the implementation a bit :-)
+
+(just missed the parens, they are there in the syntax indeed!)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, July 12, 2010  7:53 AM
+
+By the way, since I had already done all the work to carefully distinguish these
+cases without the need for parens, I put it to use in error recovery:
+
+>      1. package PexpParen is
+>      2.    function F (A : Integer)
+>      3.      return Integer is A * A;
+>                                |
+>         >>> parametrized expression must be enclosed in parentheses
+>
+>      4.    function G (A : Integer)
+>      5.      return Integer is (A * A);
+>      6. end;
+
+:-)
+
+****************************************************************
+
 From: Randy Brukardt
 Date: Wednesday, October 20, 2010  10:14 PM
 
@@ -6259,11 +6321,6 @@
 
 Treating these differently from ordinary functions seems a plain implementation
 mistake, at least in our environment.
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Date: Thursday, October 21, 2010  2:16 AM
 
 ****************************************************************