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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0177-1.txt

--- ai05s/ai05-0177-1.txt	2010/10/21 03:06:01	1.4
+++ ai05s/ai05-0177-1.txt	2010/10/26 05:28:25	1.5
@@ -1,4 +1,4 @@
-!standard  3.1(3/2)                               10-10-20    AI05-0177-1/03
+!standard  3.1(3/2)                               10-10-21    AI05-0177-1/04
 !standard  3.11.1(1/1)
 !standard  6.1(20)
 !standard  6.1(30)
@@ -6,6 +6,7 @@
 !standard  6.7(3/2)
 !standard  6.7(5/2)
 !standard  6.8(0)
+!standard  7.5(2.8/2)
 !standard  8.3(18/2)
 !standard  8.3.1(3/2)
 !standard  13.14(8/1)
@@ -18,7 +19,7 @@
 !subject Expression functions
 !summary
 
-A expression function can define the body of a function, even in a package
+An expression function can define the body of a function, even in a package
 specification. They act like default expressions for
 freezing and evaluation purposes.
 
@@ -47,7 +48,7 @@
       [overriding_indicator]
       function_specification is (<*parameterized_*expression>);
 
-[Note: The parens are needed to clearly (?) separate a expression function
+[Note: The parens are needed to clearly (?) separate an expression function
 from the start of a normal function body. Perhaps it would be
 better to use a keyword somewhere to make it crystal-clear.]
 
@@ -55,73 +56,86 @@
 of the function_specification.
 
 Within the parameterized_expression, the names of the parameters of the
-function_specification are visible.
+function_specification are directly visible.
 
 The dynamic semantics are the same as a function whose body contains nothing but
 "return parameterized_expression".
 
-A expression function can be used as a declaration or as the completion of
+An expression function can be used as a declaration or as the completion of
 a function specification. If used as a completion, the completion can be
-given anywhere in the same package (if the declaration is a package). Specifically,
-expression functions in a private part can complete function declarations
-from the visible part.
+given anywhere after the declaration in the same package (if the declaration
+is in a package). Specifically, expression functions in a private part can
+complete function declarations from the visible part.
+
+Freezing: The parameterize expression is frozen in the same way as default
+expression. That is, freezing is only be performed at the point of a call of the
+function, with the expression essentially inlined at that point. (Of course, if
+that call is in a default expression, the freezing would be deferred again.)
 
-Freezing: The renamed expression would freeze as does a default expression. That
-is, freezing would only be performed at the point of a call of the function,
-with the expression essentially in-lined at that point. (Of course, if that call
-is in a default expression, the freezing would be deferred again.)
-
 !wording
 
 Add expression_function_declaration to the list of basic_declarations in 3.1(3/2).
 
 Modify the AARM Note 3.11(10.a.1/1):
-A subprogram can be completed by a renaming-as-body{, a null_procedure_declaration, or
-an expression_function_declaration}, and we need ...
+A subprogram can be completed by a renaming-as-body{, a
+null_procedure_declaration, or an expression_function_declaration}, and we need
+...
 
-[Editor's note: This makes it clear that null procedures and expression functions used as completions
-might need an Elaboration_Check.]
+[Editor's note: This makes it clear that null procedures and expression
+functions used as completions might need an Elaboration_Check.]
 
 Modify the last sentence of 3.11.1(1/1):
 
-A body is a body, an entry_body, {a null_procedure_declaration or
-an expression_function_declaration that completes another declaration}, or a renaming-as-body (see 8.5.4).
+A body is a body, an entry_body, {a null_procedure_declaration or an
+expression_function_declaration that completes another declaration}, or a
+renaming-as-body (see 8.5.4).
 
 
 Change 6.1(20):
 ... A completion is not allowed for an abstract_subprogram_declaration{,} [or] a
-null_procedure_declaration (see 6.7){, or a expression_function_declaration (see 6.8)}.
+null_procedure_declaration (see 6.7){, or an expression_function_declaration
+(see 6.8)}.
 
 Add to the end of 6.1(30):
+
+Finally, a function defined by an expression_function_declaration is an
+expression function; a function declared by a subprogram_declaration is not. See
+6.8, "Expression Functions".
 
-Finally, a function defined by an expression_function_declaration is an expression
-function; a function declared by a subprogram_declaration is not. See 6.8, "Expression Functions". 
+[Note: The following three changes are needed to allow null procedures as
+completions; see the discussion for why this is needed.]
 
 Add after 6.7(2/3):
 
 Legality Rules
 
-A null_procedure_declaration need not be the completion of a previous declaration, but if a null_procedure_declaration
-is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration.
-The profile of a null_procedure_declaration that completes a declaration shall conform fully to that of the declaration.
+A null_procedure_declaration need not be the completion of a previous
+declaration, but if a null_procedure_declaration is a completion, it shall be
+the completion of a subprogram_declaration or generic_subprogram_declaration.
+The profile of a null_procedure_declaration that completes a declaration shall
+conform fully to that of the declaration.
 
-[Editor's note: This is mostly copied from the text for subprogram bodies, some redundancy removed.]
+[Editor's note: This is mostly copied from the text for subprogram bodies, some
+redundancy removed.]
 
 Modify 6.7(3/2):
 
-A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_declaration{,
-however a null_procedure_declaration can complete a previous declaration}.
+A null_procedure_declaration declares a null procedure. A completion is not
+allowed for a null_procedure_declaration{, however a null_procedure_declaration
+can complete a previous declaration}.
 
 Modify 6.7(5/2):
 
-The elaboration of a null_procedure_declaration has no {other} effect {than to establish that the
-expression function can be called without failing the Elaboration_Check}. 
+The elaboration of a null_procedure_declaration has no {other} effect {than to
+establish that the expression function can be called without failing the
+Elaboration_Check}.
 
 Add a new clause:
 
 6.8 Expression functions
 
-An expression_function_declaration provides a shorthand to declare a function that returns a single expression.
+An expression_function_declaration provides a shorthand to declare a function
+that returns a single expression.
 
 Syntax
 
@@ -133,70 +147,95 @@
 
 Name Resolution Rules
 
-The expected type for the *parameterized_*expression of an expression_function_declaration is
-the result type (see 6.5) of the function.
+The expected type for the *parameterized_*expression of an
+expression_function_declaration is the result type (see 6.5) of the function.
 
 Legality Rules
 
-An expression_function_declaration need not be the completion of a previous declaration, but if an expression_function_declaration
-is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration.
-The profile of a expression_function_declaration that completes a declaration shall conform fully to that of the declaration.
-
-[Editor's note: We don't need to repeat any of the Legality Rules for return statements since none of them can fail here:
-the implicit return statement has to apply to this function (and isn't nested), there clearly is a return statement in this function,
-and none of the accessibility rules can fail because there can be no local declarations here.]
+An expression_function_declaration need not be the completion of a previous
+declaration, but if an expression_function_declaration is a completion, it shall
+be the completion of a subprogram_declaration or generic_subprogram_declaration.
+The profile of an expression_function_declaration that completes a declaration
+shall conform fully to that of the declaration.
+
+If the result subtype has one or more unconstrained access discriminants, the
+accessibility level of the anonymous access type of each access discriminant, as
+determined by the *paarameterized_*expression, shall not be statically deeper
+than that of the master that elaborated the expression_function_declaration.
+
+AARM Ramification: This can only fail if the discriminant is an access to a part
+of a non-aliased parameter, as there can be no local declarations here.
+
+AARM Discussion: We don't need to repeat any of the other Legality Rules for
+return statements since none of them can fail here: the implicit return
+statement has to apply to this function (and isn't nested in something), there
+clearly is a return statement in this function, and the static classwide
+accessibility check cannot fail as a tagged type cannot be declared locally in
+this function.]
 
 Static Semantics
 
-An expression_function_declaration declares an expression function. A completion is not allowed for an expression_function_declaration,
-however an expression_function_declaration can complete a previous declaration.
+An expression_function_declaration declares an expression function. A completion
+is not allowed for an expression_function_declaration, however an
+expression_function_declaration can complete a previous declaration.
 
 Dynamic Semantics
-
-The execution of an expression function is invoked by a subprogram call. For the execution of a
-subprogram call on an expression function, the execution of the subprogram_body is equivalent to a
-function body containing only a simple_return_statement that returns the *parameterized_*expression. 
-
-AARM Discussion: The last sentence effectively means that all of the dynamic wording in 6.5 applies as
-needed, and we don't have to repeat it here.
 
-The elaboration of a expression_function_declaration has no other effect than to establish that the
-expression function can be called without failing the Elaboration_Check. 
+The execution of an expression function is invoked by a subprogram call. For the
+execution of a subprogram call on an expression function, the execution of the
+subprogram_body is equivalent to a function body containing only a
+simple_return_statement that returns the *parameterized_*expression.
+
+AARM Discussion: The last sentence effectively means that all of the dynamic
+wording in 6.5 applies as needed, and we don't have to repeat it here.
+
+The elaboration of an expression_function_declaration has no other effect than
+to establish that the expression function can be called without failing the
+Elaboration_Check.
 
 Examples
 
 function Is_Origin (P : in Point) return Boolean is -- see 3.9
     (P.X = 0 and P.Y = 0);
 
+Add new bullet after 7.5(2.8/2):
 
+* the *parameterized_*expression of an expression_function_declaration (see 6.8)
+
 Modify 8.3(18/2):
 
-* For a package_declaration, task declaration, protected declaration, generic_package_declaration, [or] subprogram_body{, or
-  expression_function_declaration}, the declaration is hidden from all visibility only until the reserved word is of the declaration;.
+* For a package_declaration, task declaration, protected declaration,
+  generic_package_declaration, [or] subprogram_body{, or
+  expression_function_declaration}, the declaration is hidden from all
+  visibility only until the reserved word is of the declaration;.
 
-[Editor's note: We need this to make the parameters visible in the *parameterized_*expression of
-an expression_function_declaration.]
+[Editor's note: We need this to make the parameters visible in the
+*parameterized_*expression of an expression_function_declaration.]
 
-Add expression_function_declaration into the list of 8.3.1(3/2), after null_procedure_declaration.
+Add expression_function_declaration into the list of 8.3.1(3/2), after
+null_procedure_declaration.
 
 Modify 13.14(8/1):
 
-A static expression causes freezing where it occurs. An object name or nonstatic expression causes freezing
-where it occurs, unless the name or expression is part of a default_expression, a default_name, 
-{the *parameterized_*expression of an expression function,} or a per-object expression of a component's
-constraint, in which case, the freezing occurs later as part of another construct.
+A static expression causes freezing where it occurs. An object name or nonstatic
+expression causes freezing where it occurs, unless the name or expression is
+part of a default_expression, a default_name, {the *parameterized_*expression of
+an expression function,} or a per-object expression of a component's constraint,
+in which case, the freezing occurs later as part of another construct.
 
 Modify 13.14(10.1/3) [as added by AI05-0019-1]:
 
-At the place where a function call causes freezing, the profile of the function is frozen. Furthermore,
-if a parameter of the call is defaulted, the default_expression for that parameter causes freezing.
-{If the function call is to an expression function, the *parameterized_*expression for the expression
+At the place where a function call causes freezing, the profile of the function
+is frozen. Furthermore, if a parameter of the call is defaulted, the
+default_expression for that parameter causes freezing. {If the function call is
+to an expression function, the *parameterized_*expression for the expression
 function causes freezing.}
 
-AARM Ramification: Freezing of the *parameterized_*expression only needs to be considered when the
-expression function is in the same compilation unit and there are no intervening bodies; the end of a
-declarative_part or library package freezes everything in it, and a body freezes everything declared
-before it.
+AARM Ramification: Freezing of the *parameterized_*expression only needs to be
+considered when the expression function is in the same compilation unit and
+there are no intervening bodies; the end of a declarative_part or library
+package freezes everything in it, and a body freezes everything declared before
+it.
 
 
 !discussion
@@ -205,36 +244,37 @@
 
 These have been variously called expression renaming, parameterized expressions,
 and expression functions. Parameterized expressions best explains the intended
-use, but we named these expression functions as that works better with the existing
-wording. The primary issue is that an expression function either declares a
-subprogram or completes a subprogram. The vast majority of rules that apply to
-functions and more generally subprograms also apply to expression functions.
-If we called them parameterized expressions, neither the word "subprogram" nor
-"function" would appear; that would mean that additional wording would be needed
-to ensure that they are properly included in "function" and "subprogram" rules.
+use, but we named these expression functions as that works better with the
+existing wording. The primary issue is that an expression function either
+declares a subprogram or completes a subprogram. The vast majority of rules that
+apply to functions and more generally subprograms also apply to expression
+functions. If we called them parameterized expressions, neither the word
+"subprogram" nor "function" would appear; that would mean that additional
+wording would be needed to ensure that they are properly included in "function"
+and "subprogram" rules.
 
 We did "borrow" the parameterized expression name to mean the actual expression
-of an expression function. This simplifies some of the wording and re-enforces
+of an expression function. This simplifies some of the wording and reinforces
 the usage intent.
 
 ---
 
-A goal for expression functions is that they represent a subset of the capabilities
-of null subprograms in terms of the use as subprogram. If we didn't do that, we would
-have added another kind of subprogram, whose usages would be subtlely different than
-the existing kinds. That seems bad.
-
-In order to accomplish this, we added the capability of a null subprogram to represent
-a completion. This is not an important capability, but it increases the consistency
-of the various kinds of subprogram declaration.
+A goal for expression functions is that they represent a subset of the
+capabilities of null subprograms in terms of the use as subprogram. If we didn't
+do that, we would have added another kind of subprogram, whose usages would be
+subtlely different than the existing kinds. That seems bad.
+
+In order to accomplish this, we added the capability of a null subprogram to
+represent a completion. This is not an important capability, but it increases
+the consistency of the various kinds of subprogram declaration.
 
 ---
 
-One could imagine these functions (when visible) to be used in
-static expressions if the inlined expression would be static. This would
-definitely allow abstracting expressions that currently are written as a
-giant single expression because they need to be static. That's something you
-cannot do now. I didn't add this to proposal in order to keep the proposal simple.
+One could imagine these functions (when visible) to be used in static
+expressions if the inlined expression would be static. This would definitely
+allow abstracting expressions that currently are written as a giant single
+expression because they need to be static. That's something you cannot do now. I
+didn't add this to proposal in order to keep the proposal simple.
 
 ---
 
@@ -254,10 +294,10 @@
 ---
 An additional idea would be to allow this as a primitive subprogram of an
 interface. If we did that, we would get the benefit of the identity function
-idea (see AI05-0140-1) without adding anything special specifically for that case.
-The expression would have to be included in the 8.3 homograph
-matching rules, probably by borrowing the rules for full conformance of expressions.
-That would be necessary to deal with the Steve Baird problem for diamond inheritance
+idea (see AI05-0140-1) without adding anything special specifically for that
+case. The expression would have to be included in the 8.3 homograph matching
+rules, probably by borrowing the rules for full conformance of expressions. That
+would be necessary to deal with the Steve Baird problem for diamond inheritance
 with interfaces (that was the primary reason that AI05-0140-1 was scuttled).
 
 Including both this and the formal subprogram default would make this completely
@@ -3444,6 +3484,2624 @@
 The assignment operator seems much more sensible to me.
 
 ****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  12:57 PM
+
+I don't think "in" works, because:
+
+    A : Integer := 123;
+
+    X := (Y = A in B in C);
+
+Does that mean Y is is of type Integer, value 123, and the expression is "B in
+C"?  Or is Y of type Boolean, value "A in B", and the expression is "C"?
+
+We don't want the type of X to help resolve this ambiguity!
+
+Somebody suggested "do", which I can live with.
+
+****************************************************************
+
+From: Steve Baird
+Date: Monday, May 3, 2010  1:18 PM
+
+> Do we really want to use "=" for these rather than ":="?
+> The assignment operator seems much more sensible to me.
+
+I agree - I don't like this use of "=".
+
+I would actually prefer "=>" because we are (in some sense) specifying a
+parameter value, but I'm afraid that would end up looking too much like an
+aggregate.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, May 3, 2010  1:25 PM
+
+> Do we really want to use "=" for these rather than ":="?
+> The assignment operator seems much more sensible to me.
+
+The idea of "=" was that this was more of an assertion that X = <expr> in the
+expression.  Using ":=" makes these look very much like assignment statements,
+which they definitely are not.  They are closer to renamings.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, May 3, 2010  1:29 PM
+
+I prefer "=>" or "=" to ":=".
+":=" just makes these look too much like assignment statements.
+
+It seems OK to have them look a bit like aggregates.
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  2:13 PM
+
+> I prefer "=>" or "=" to ":=".
+> ":=" just makes these look too much like assignment statements.
+
+I agree with Tucker that we don't want these to look like assignment statements.  (But then, I already dislike the fact that initialization uses the same symbol as assignment statements.)
+
+> It seems OK to have them look a bit like aggregates.
+
+I suppose so.
+
+"=" rubs me the wrong way, because this really is an assignment (i.e. an
+initialization), not an equality test, and I am annoyed by languages that misuse
+maths notations well-established for hundreds of years.
+
+I guess "=>" is best.
+
+Other ideas?  How about "is"?  "with X is Y*Y do X + X"
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Monday, May 3, 2010  2:20 PM
+
+"=>" is already used to indicate a binding of a name to a value,  it seems
+natural to use it here as well.
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Monday, May 3, 2010  2:22 PM
+
+> The idea of "=" was that this was more of an assertion that X = <expr>
+> in the expression.  Using ":=" makes these look very much like
+> assignment statements, which they definitely are not.  They are closer
+> to renamings.
+
+It depends on how these are bound.  In the earlier discussion they were being
+discussed as being like constants, not renamings.
+
+In fact, you wrote:
+
+> You could perhaps use "with...do" instead of "let ... in"
+>
+>    (with A = <expression>, B = <expression>, ... do ...)
+>
+> If these are all constants, I don't see the need for
+> ": constant <type> :=" when "=" will do.
+
+(though I would have said: when ":=" will do.:-)
+
+Normally there won't be a semantic difference whether they're semantically
+constants or renamings, but there would be if there's a possibility of
+intervening side effects.  And I assume that is possible in general, since these
+are just a kind of expression.
+
+If we want them to be a shorthand for the "expression function" thingies, OK,
+then renaming semantics makes sense.
+
+In any case, I'd prefer "=>" over "=", and sounds like you're OK with that.
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Monday, May 3, 2010  2:42 PM
+
+> I agree with Tucker that we don't want these to look like assignment
+> statements.  (But then, I already dislike the fact that initialization
+> uses the same symbol as assignment statements.)
+
+Fair enough.  I just thought it was consistent with how initialized declarations
+look (whether or not you like those:-).
+
+> > It seems OK to have them look a bit like aggregates.
+>
+> I suppose so.
+
+It's OK, but not great.  It's kind of annoying to have something initially read
+a lot like something else that's quite different, but I suppose I can live with
+it.  (Almost looks like an extension aggregate, but missing the ancestor
+part...)
+
+> "=" rubs me the wrong way, because this really is an assignment (i.e.
+> an initialization), not an equality test, and I am annoyed by
+> languages that misuse maths notations well-established for hundreds of
+> years.
+
+So you agree that this is an assignment binding, not like a renaming.
+That's indeed what I thought you originally intended when you suggested having a
+"let".  Anyway, I agree that using "=" would be annoying and confusing.
+
+> I guess "=>" is best.
+>
+> Other ideas?  How about "is"?  "with X is Y*Y do X + X"
+
+Probably "=> is the way to go.  "is" might be OK, but I think it reads kind of
+funny, especially for cases where you have more than one of them.
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  2:51 PM
+
+> So you agree that this is an assignment binding, not like a renaming.
+
+Yes, definitely.  It's a shorthand for a constant decl.
+Treating it as a renaming (of what?  possibly a variable?) makes no sense to me.
+
+But I suppose I should retract my comment about misuse of maths notations --
+"let X = 2 + 2" is a perfectly good maths notation.  So I don't know. And don't
+care too much -- I like the feature a lot, and could live with most of the
+syntax suggestions.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010  6:36 PM
+
+> I don't think "in" works syntactically, but perhaps "do".
+
+Right, sorry, I meant to write "do"
+
+Some minor points,
+
+the names in the declarations are local to the expression and following
+declarations I assume.
+
+the expression itself gets full overloading treatment I assume (that's actually
+the hardest thing to implement, because otherwise you can turn the expression
+trivially into a function, to deal with the local scoping etc, but you can't do
+that because of the overloading, which can't be done until you have all the
+declarations resolved, a bit tricky, but nothing insuperable.
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  7:19 PM
+
+> the names in the declarations are local to the expression and
+> following declarations I assume.
+
+Yes, I agree.
+
+> the expression itself gets full overloading treatment I assume (that's
+> actually the hardest thing to implement, because otherwise you can
+> turn the expression trivially into a function, to deal with the local
+> scoping etc, but you can't do that because of the overloading, which
+> can't be done until you have all the declarations resolved, a bit
+> tricky, but nothing insuperable.
+
+I'm not sure what you mean by "full overloading treatment".
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010  8:18 PM
+
+> I'm not sure what you mean by "full overloading treatment".
+
+I mean that you can say
+
+     f (g (with a => 2, m (a)));
+
+and you have to consider various f's, g's and m's in figuring this out. the
+expression is not (unlike the right side of the declarations) an isolated
+context.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010  6:40 PM
+
+> I would actually prefer "=>" because we are (in some sense) specifying
+> a parameter value, but I'm afraid that would end up looking too much
+> like an aggregate.
+
+I really don't like := for a binding, but perhaps that's my Algol-68 background,
+yes, I can buy Constant together with := meaning binding, but I don't like
+
+    a := 3
+
+meaning initialization rather than assignment
+
+I would go for the =>
+
+and not worry about the aggregate issue (it will be very rare to have a string
+of more than one of these declarations anyway, and the WITH keyword is close by
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010   6:45 PM
+
+> It's OK, but not great.  It's kind of annoying to have something
+> initially read a lot like something else that's quite different, but I
+> suppose I can live with it.  (Almost looks like an extension
+> aggregate, but missing the ancestor part...)
+
+But it's got (with
+
+which is an unambiguous clue!
+
+>> "=" rubs me the wrong way, because this really is an assignment (i.e.
+>> an initialization), not an equality test, and I am annoyed by
+>> languages that misuse maths notations well-established for hundreds
+>> of years.
+
+no no no!
+
+In Algol-68
+
+    int a = 3
+
+is a BINDING, not an initialization, and the use of the equal sign is really
+appropriate for a binding if you ask me. So I like that syntax,
+
+but it's not Ada, so let's stick with =>
+
+This has the advantage of not getting confused with normal declaration syntax.
+
+...
+>> Other ideas?  How about "is"?  "with X is Y*Y do X + X"
+>
+> Probably "=> is the way to go.  "is" might be OK, but I think it reads
+> kind of funny, especially for cases where you have more than one of them.
+
+I agree
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  7:13 PM
+
+> is a BINDING, not an initialization, and the use of the equal sign is
+> really appropriate for a binding if you ask me.
+
+ok ok ok, I already retracted my rant about "maths" above.
+
+>... So
+> I like that syntax,
+
+Me, too (now).
+
+> but it's not Ada, so let's stick with =>
+
+OK with me.
+
+> This has the advantage of not getting confused with normal declaration
+> syntax.
+
+I don't get that.  It's exactly equivalent to a normal constant decl.
+What confusion are you talking about?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010  8:17 PM
+
+>> is a BINDING, not an initialization, and the use of the equal sign is
+>> really appropriate for a binding if you ask me.
+
+You know that in Algol-68 this binding notion is universal, so a variable is
+declared using
+
+    ref int a = loc int [:= 3];
+
+Here the identifier a is a reference to an integer, and it is bound to the
+result of calling a local allocator that allocates space on the local stack,
+then you can optionally initialize as shown. As you can imagine, compilers are
+likely to optimize this particular case of binding, but a renaming is not a
+special case, after the above declaration you can say
+
+    ref int b = a;
+
+and now b and a are bound to the same location
+
+Unfortunately Algol-68 was too scared of this notation, and introduced the short
+hand
+
+    int a;
+
+which is if you ask me an abomination (sort of like the decision to introduce
+anonymous arrays in Ada to make the Fortran folks happy).
+
+Worse still
+
+    int a := 3;
+
+is a shorthand for
+
+    ref int a = loc int := 3;
+
+and is only one character different from
+
+    int a = 3;
+
+I really like that in Algol-68, there is LESS syntax for constants, it is
+annoying that it is the other way round in Ada.
+
+But I digress, please enter sufficient ^H characters to delete this irrelevant
+rambling.
+
+I think we have a consensus on the use of =>
+
+so now we have
+
+   (with DECL {, DECL} do EXPRESSION)
+
+where DECL looks like
+
+    IDENTIFIER => EXPRESSION
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, May 3, 2010  8:50 PM
+
+> But I digress, please enter sufficient ^H characters to delete this
+> irrelevant rambling.
+
+I agree with much of the above digression, both the elegance of Algol 68, and
+the inelegance of the shorthands.
+
+The main thing I don't like is that pointers (refs) are the same as variables.
+
+And please ^H-ify this to one's heart's content.
+
+> I think we have a consensus on the use of =>
+>
+> so now we have
+>
+>    (with DECL {, DECL} do EXPRESSION)
+>
+> where DECL looks like
+>
+>     IDENTIFIER => EXPRESSION
+
+Yes, "looks like", but in the BNF in the RM, DECL will need to be something
+like:
+
+    with_declaration ::= defining_identifier => expression
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, May 3, 2010  9:02 PM
+
+> Yes, "looks like", but in the BNF in the RM, DECL will need to be
+> something
+> like:
+>
+>     with_declaration ::= defining_identifier => expression
+
+yes sure, I was just indicating the surface syntax
+
+I would call it with_expression_declaration, since with_declaration seems to
+confusable with with statements.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, May 3, 2010  9:46 PM
+
+...
+> I think we have a consensus on the use of =>
+>
+> so now we have
+>
+>    (with DECL {, DECL} do EXPRESSION)
+>
+> where DECL looks like
+>
+>     IDENTIFIER => EXPRESSION
+
+This seems OK, but let me step back a bit and make a few reasonably general
+comments.
+
+First, can someone make a reasonably concise statement of the problem this is
+intended to solve? The only thing I've seen from this thread is that it seems
+inexplicably make Bob more comfortable with expression functions. While that's
+probably a useful goal, I don't see how that's going to help us sell this to the
+Ada community at large. Some people (not on the ARG!) already have objected to
+conditional expressions, and this of course is much more strongly in the same
+direction.
+
+After all, this is a fairly complex feature to define and implement (we'll need
+to make sure that we don't make the same mistake we made with extended returns,
+for instance, so that the newly defined identifier is actually visible after the
+"do"). We will need a decent justification for it.
+
+I admit that I'm a bit dubious about the need for constants. I've been racking
+my brain and can't remember a case where I wanted a constant to use in a single
+expression (variables are different, see below). I realize that conditional
+expressions (both types) could potentially make expressions larger, but I've
+been hoping that the provision of expression functions would tend to limit the
+size of expressions -- if they get too large, it is better to create an
+abstraction to represent parts and break them up.
+
+I do strongly prefer the "=>" notation, as we definitely do not want these to
+look like declarations. Otherwise, we'd have endless arguments about why
+variables aren't allowed (or whether they should be allowed). The only cases I
+can think of where I've used local objects for a single expression is to discard
+unnecessary in out and out parameters. With the additional of in out parameters
+to functions, we now will have this problem in function calls as well. This is
+especially common when interfacing to existing APIs.
+
+I believe also that the intent is that this entire construct is an expression.
+That means that it can't be used in assignment contexts (lvalues in C). That's
+probably a good thing; recall however that it can be turned into a "name" by
+qualifying it, so it will be possible to rename and use it in other contexts
+that require a (constant) name.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, May 3, 2010  10:22 PM
+
+One more point: we need to clearly decide whether DECL is a renaming or whether
+it declares a new constant object. The semantics can be different, and it can
+matter (for instance, to the "known to be the same object" rules, and whether
+Adjust is called for controlled components).
+
+We seem to have had votes for both possibilities in the previous discussion.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  6:05 AM
+
+> First, can someone make a reasonably concise statement of the problem
+> this is intended to solve? The only thing I've seen from this thread
+> is that it seems inexplicably make Bob more comfortable with expression functions.
+
+not at all inexplicable! if you insist that the "body" of such an expression
+function be a single expression, or that you want to be able to write powerful
+expressions in preconditions etc, you need this very standard capability. Randy,
+do you have experience with the use of LET expressions (we are not inventing
+anything new here, all functional languages have this capability).
+
+Generally, we say we don't need this because we can write separate declarations
+(it's really Bob's preference to do that anyway by allowing bodies in specs),
+but if we don't allow separate declarations, this is a very necessary
+abstraction facility.
+
+It is often also a much more convenient form for local abstraction.
+Consider something like
+
+      declare
+         A : Float := Factor * Adjustment;
+      begin
+         return A * A + A;
+      end;
+
+This reads fine and is much shorter:
+
+      return (with A = Factor * Adjustment do A * A + A);
+
+> While that's probably a useful goal, I don't see how that's going to
+> help us sell this to the Ada community at large.
+
+I think no changes we do to the language are specifically much help in selling
+to the Ada community, other than to show a general activity in keeping Ada
+current and showing continued interest. After all our (our = AdaCore for this
+sentence) major competitor, Greenhills, has decided it is not even worth
+investing in Ada 2005, let alone Ada 2012.
+
+On the other hand, for certain specific customers, pre/post conditions with the
+ability to write powerful expressions are a real plus. We put in pre/post
+conditions not because of anything the ARG was doing, but because a critical
+customer needed this capability (we will keep these pragmas around for ever, and
+likely they will in practice be more heavily used than the eventual aspect
+syntax, which of course we will eventually support).
+
+> Some people (not on the ARG!)
+> already have objected to conditional expressions, and this of course
+> is much more strongly in the same direction.
+
+Ah, the infamous "some people". Who are these people? Do they know anything? And
+what specifically is their objection to conditional expressions (which are by
+the way a VERY nice improvement, we have redone our run-time library with
+judicious but fairly extensive use of conditional expressions, and it is a big
+improvement).
+
+> After all, this is a fairly complex feature to define and implement
+> (we'll need to make sure that we don't make the same mistake we made
+> with extended returns, for instance, so that the newly defined
+> identifier is actually visible after the "do"). We will need a decent justification for it.
+
+Not so hard to implement, maybe a day or two's work for us, and as for other
+compilers, we don't even see them implementing critical 2005 features yet, so I
+can't get to excited about difficulty-of-implementation arguments
+
+As for difficulty-of-definition, I don't see a problem, it is certainly nothing
+like the extended return (which was a HUGE pain in the neck, and for me a case
+where the implementation and definition efforts were unreasonably large. For me
+the second most glaring example of a mismatch between effort and value -- the
+first being leap seconds, about which don't get me started!)
+
+> I admit that I'm a bit dubious about the need for constants. I've been
+> racking my brain and can't remember a case where I wanted a constant
+> to use in a single expression (variables are different, see below). I
+> realize that conditional expressions (both types) could potentially
+> make expressions larger, but I've been hoping that the provision of
+> expression functions would tend to limit the size of expressions -- if
+> they get too large, it is better to create an abstraction to represent parts and break them up.
+
+That's strage to me, I guess it's just a frame of mind, have you ever done
+significant programming in a functional language?
+
+> I do strongly prefer the "=>" notation, as we definitely do not want
+> these to look like declarations. Otherwise, we'd have endless
+> arguments about why variables aren't allowed (or whether they should
+> be allowed). The only cases I can think of where I've used local
+> objects for a single expression is to discard unnecessary in out and out parameters.
+
+Why would you "discard" unnecessary parameters, why not just ignore them,
+confused ....
+
+> With the additional of in out
+> parameters to functions, we now will have this problem in function
+> calls as well. This is especially common when interfacing to existing APIs.
+>
+> I believe also that the intent is that this entire construct is an
+> expression. That means that it can't be used in assignment contexts
+> (lvalues in C). That's probably a good thing; recall however that it
+> can be turned into a "name" by qualifying it, so it will be possible
+> to rename and use it in other contexts that require a (constant) name.
+
+Right, the entire construct is an expression, as in C, and unlike Algol-68.
+That's a limitation, we don't allow something like
+
+    (if X then A else B) := large complex expression;
+
+which is sometimes useful (as in Algol-68 use), but it's not Ada so that's that!
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  6:06 AM
+
+> One more point: we need to clearly decide whether DECL is a renaming
+> or whether it declares a new constant object. The semantics can be
+> different, and it can matter (for instance, to the "known to be the
+> same object" rules, and whether Adjust is called for controlled components).
+
+I would be in favor of it being a new constant object (really a value, but I
+know Ada likes to call values objects :-( ) My limited knowledge of Ada finds
+the idea of renaming an expression plain odd.
+
+> We seem to have had votes for both possibilities in the previous discussion.
+
+Can someone post a clear example where it makes a semantic difference.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010   6:12 AM
+
+By the way, the reason I like to think of the "declarations" as constants rather
+than objects, is that for me, the following are equivalent (using equivalent in
+the Ada technical sense of very similar, but not quite the same :-))
+
+
+    (with
+       A = 3 * Q,
+       B = C * A
+     in
+       B * B + B)
+
+(I think I like this indenting style by the way
+
+
+    function T return Integer is
+      A : constant Integer := 3 * Q;
+      B : constant Integer := C * A;
+    begin
+      return B * B + B;
+    end T;
+
+then you replace the expression with a call to T
+
+It can't be implemented that way unfortunately (otherwise the implementation
+would be really trivial), since you don't know the types involved.
+
+The implementation I have in mind, is simply to insert the declarations:
+
+     A : constant Integer := 3 * Q;
+     B : constant Integer := C * A;
+
+before the expression in question (we have a quite general insertion mechanism
+that can do this), then just replace the where expression with the constituent
+expression.
+
+The difficulty is that the names A and B have to be marked to make them unique,
+since they are not accessible other than in the target expression.
+
+That's not a big deal, except to make sure that the debugger can handle them OK.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  7:56 AM
+
+I prefer to think of it as a renaming
+of the result of a function call,
+rather than making a copy.
+Equivalently, it could be thought of
+as the same kind of binding that occurs
+with an IN parameter.  We really don't
+want copies made here of composite objects, in my view, with the attendant
+adjusts and finalizes.
+
+Given the use of "=>", using the IN parameter model is perhaps the best.  On the
+other hand, the advantage of renaming is that it inherits aliasedness,
+accessibility, etc., whereas a parameter loses some of that information.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  8:02 AM
+
+I would go with the renaming, now that I understand the issue, I think it unlikely that the lack of inheritance is an issue for the kind of thing we are likely to encounter, but it does seem useful to be able to use this as in
+
+    (with
+       R => Very_Important_Record_With_Long_Name
+     do R.X + R.Y + R.Z)
+
+without generating a copy
+
+Of course if you go to the full declaration syntax, you could simply allow
+renames, and let the user decide.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  8:21 AM
+
+> I prefer to think of it as a renaming
+> of the result of a function call,
+> rather than making a copy.
+> Equivalently, it could be thought of
+> as the same kind of binding that occurs with an IN parameter.  We
+> really don't want copies made here of composite objects, in my view,
+> with the attendant adjusts and finalizes.
+
+Why you say "my view", I think you owe us an explanation of why.
+An argument with concrete reasons is always more compelling than an argument
+from authority, even when I have great respect for the authority -- Tucker Taft
+is indeed a world-renowned authority with (mostly) good taste in language
+design!  ;-)
+
+Maybe you're worried about the inefficiency of adjusts, maybe it's something
+else, but I can't guess.
+
+> Given the use of "=>", using the IN parameter model is perhaps the
+> best.  On the other hand, the advantage of renaming is that it
+> inherits aliasedness, accessibility, etc., whereas a parameter loses
+> some of that information.
+
+I don't much like the renaming idea, because it introduces an alias, which is
+error prone.  The IN param idea seems even worse, because then it's
+implementation dependent whether or not it introduces an alias.  To me, this
+feature looks like a shorthand for declaring a constant inside an expression.
+This would imply that it's illegal for limited types, unless the initial value
+is a function call or aggregate (b-i-p).
+
+Note that in the last year or so, GNAT added a warning about renaming of
+function calls, which could better be expressed by declaring a constant, because
+some users found it confusing -- the got mixed up about the syntax, and thought
+they were renaming the function, when they were renaming the result of calling
+it.
+
+Note that we already have permissions to avoid redundant adjust/finalize, and
+compilers can also avoid copies of non-controlled things in many cases.  So I'm
+not concerned about efficiency.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  8:36 AM
+
+> Why you say "my view", I think you owe us an explanation of why.
+
+I see this as a light weight feature,
+and having hidden calls on finalize and
+adjust add weight and complexity.  The semantics of renaming seem just right.
+Any aliases created are totally visible, so there is no difficulty from the
+compiler's point of view, and if the user chooses to use both the original and
+the renaming in this one expression, I think they definitely fall into your
+bucket of actively trying to make a mess of things... ;-).
+
+Note that the only time an alias would be created would be if the right hand
+side of the binding were a pre-existing object, and in that case, it is quite
+possibly a short-hand you are seeking rather than a full copy
+
+As far as renaming of the results of functions, it has been in the language for
+15 years, and I find the new GNAT warning somewhat annoying, though I presume
+they didn't put it in to help (or annoy ;-) folks like me.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  9:09 AM
+
+> As far as renaming of the results of functions, it has been in the
+> language for 15 years, and I find the new GNAT warning somewhat
+> annoying, though I presume they didn't put it in to help (or annoy ;-)
+> folks like me.
+
+It's peculiar to do a renaming of a function that returns a scalar result in my
+view, it is confusing to readers who are not Tucker Taft, and it achieves
+nothing whatever.
+
+You can always suppress the specific warning if you don't like it.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  9:21 AM
+
+> I see this as a light weight feature,
+> and having hidden calls on finalize and adjust add weight and
+> complexity.  The semantics of renaming seem just right.  Any aliases
+> created are totally visible, so there is no difficulty from the
+> compiler's point of view, and if the user chooses to use both the
+> original and the renaming in this one expression, I think they
+> definitely fall into your bucket of actively trying to make a mess of
+> things... ;-).
+
+My concern is about accidental misuse and readability, not deliberate abuse.
+
+But I must admit that I'm being inconsistent in worrying about this, while
+advocating 'in out' params on functions.
+
+> Note that the only time an alias would be created would be if the
+> right hand side of the binding were a pre-existing object, and in that
+> case, it is quite possibly a short-hand you are seeking rather than a
+> full copy
+>
+> As far as renaming of the results of functions, it has been in the
+> language for 15 years,
+
+Age is not an argument for or against a feature.
+
+I tend to use constants rather than renamings when possible, and trust the
+compiler to remove copies when possible, because constants are a weaker, less
+powerful, easier-to-understand feature.  I use renamings when I want the extra
+power.
+
+> and I find the new GNAT warning somewhat annoying,
+
+I know.
+
+> though I presume they didn't put it in to help (or annoy ;-) folks
+> like me.
+
+You presume correctly.  ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  9:21 AM
+
+> It's peculiar to do a renaming of a function that returns a scalar
+> result in my view, it is confusing to readers who are not Tucker Taft,
+> and it achieves nothing whatever.
+
+I generally only use it for composite/private types, and generally only in a
+local declare block to hold a large intermediate in some calculation.
+
+> You can always suppress the specific warning if you don't like it.
+
+I think the warning doesn't distinguish elementary from composite.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  9:32 AM
+
+> I tend to use constants rather than renamings when possible, and trust
+> the compiler to remove copies when possible...
+
+I know too much about compilers to ever really trust them to do optimizations.
+And when they actually change the semantics, such as removing redundant
+finalize/adjusts, this is pushing what some compiler-writers feel comfortable
+doing, and certainly isn't something that a "typical" language-independent
+optimizer is going to do.
+
+And since the alternative is often to write the somewhat complex function call
+in the single place it is used, a "rename" preserves the same semantics, whereas
+a copy can change things subtly and certainly can slow things down.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  9:39 AM
+
+>> You can always suppress the specific warning if you don't like it.
+>
+> I think the warning doesn't distinguish elementary from composite.
+
+It doesn't, but the customer cases which lead to this warning were in fact
+composite types. We found people having consistently wrong expectations in the
+use of this "feature" (i actually think it is a bit of a misfeature), and not
+one case of a reasonable use in our whole test suite (but several suspicious
+ones). Style warnings are always tricky :-)
+
+Note that you are turning this warning on if you are seeing it, either with
+-gnatwa or with -gnatw.r explicitly. I suggest turning it off if you don't like
+it, use
+
+-gnata.R
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  9:53 AM
+
+> ...And what specifically is their objection to conditional expressions
+
+I'm curious about that, too.
+
+The only case I remember is when they were discussed during Ada 9X, and John
+Goodenough objected, with the reason "Ada is not an expression language".
+
+> As for difficulty-of-definition, I don't see a problem, it is
+> certainly nothing like the extended return (which was a HUGE pain in
+> the neck, and for me a case where the implementation and definition
+> efforts were unreasonably large.
+
+Extended return statements are trivial to define and to implement -- they're
+just syntactic sugar.
+
+Build-in-place function calls were a HUGE pain.  Don't confuse these two
+features; they're not the same thing.
+
+> Why would you "discard" unnecessary parameters, why not just ignore
+> them, confused ....
+
+I think Randy means a procedure with an 'out' parameter, and he wants to throw
+away the value returned in that parameter.  So he declares a very-local variable
+called Ignore, say, and passes that.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  10:10 AM
+
+> Extended return statements are trivial to define and to implement --
+> they're just syntactic sugar.
+>
+> Build-in-place function calls were a HUGE pain.  Don't confuse these
+> two features; they're not the same thing.
+
+Indeed I referred to the second in my comment, I think of them as one feature
+:-)
+
+>> Why would you "discard" unnecessary parameters, why not just ignore
+>> them, confused ....
+>
+> I think Randy means a procedure with an 'out' parameter, and he wants
+> to throw away the value returned in that parameter.  So he declares a
+> very-local variable called Ignore, say, and passes that.
+
+Ah yes, that makes perfect sense
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  10:26 AM
+
+> > Extended return statements are trivial to define and to implement --
+> > they're just syntactic sugar.
+> >
+> > Build-in-place function calls were a HUGE pain.  Don't confuse these
+> > two features; they're not the same thing.
+>
+> Indeed I referred to the second in my comment, I think of them as one
+> feature :-)
+
+Everybody does, which is why I keep pointing out that they're not.  ;-)
+
+They are related, in that there are some cases of build-in-place where you
+really need to use the extended return syntax.  And they are related in that
+they were invented at the same time.
+
+But it's important to remember that this syntax does not trigger B-I-P. B-I-P is
+triggered by limitedness, and it works even when the old-fashioned simple return
+syntax is used.
+
+In a non-B-I-P situation, extended return syntax is never necessary, but it is a
+convenient shorthand.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  10:45 AM
+
+> Everybody does, which is why I keep pointing out that they're not.
+> ;-)
+
+Right, but to me the extended return is a pretty minimal-use piece of syntactic sugar. I wouldn't be in favor of adding it if it was not needed in some cases, so I think it is reasonable to think of them as one feature!
+
+>
+> They are related, in that there are some cases of build-in-place where
+> you really need to use the extended return syntax.  And they are
+> related in that they were invented at the same time.
+>
+> But it's important to remember that this syntax does not trigger B-I-P.
+> B-I-P is triggered by limitedness, and it works even when the
+> old-fashioned simple return syntax is used.
+>
+> In a non-B-I-P situation, extended return syntax is never necessary,
+> but it is a convenient shorthand.
+
+I find it dubious ... I never use it myself.
+
+Of course this is all a bit colored by the fact that I regard the change to
+limited type return as a non-compatible disaster in the language design, which
+has badly hindered our customers from transitioning to Ada 2005, and results in
+continued horrible problems in mixing Ada 95 and Ada 2005. :-)
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  10:03 AM
+
+> Can someone post a clear example where it makes a semantic difference.
+
+Here's an example, although I'm not sure it's "clear":
+
+    Var : aliased Integer := 123;
+
+    X : constant Integer :=
+        (with My_Var => Var do
+            (F (Out_Param => My_Var) -- (1)
+             G (Access_Param => My_Var'Access) -- (2)
+             H (Named_Access => My_Var'Access) -- (3)
+            )
+        );
+
+With renaming semantics, all of the above are legal, and the run-time
+accessibility check for (2) inside G uses the level of Var. (Well, (3) is legal
+only if the type is at the same level as Var.)
+
+With constant semantics, (1) is illegal because it's trying to pass a constant
+as a 'out' parameter.  (2) is illegal if the parameter is access-to-variable,
+and if access-to-constant, passes a deeper accessibility level than renaming
+would. (3) is illegal because My_Var is deeper than the access type.
+
+It would also make a difference if Var is atomic or volatile -- renaming
+inherits these properties; a constant would not.
+
+I guess this is somewhat convincing that "rename" vs. "constant"
+won't matter in practice.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  10:23 AM
+
+>     X : constant Integer :=
+>         (with My_Var => Var do
+>             (F (Out_Param => My_Var) -- (1)
+>              G (Access_Param => My_Var'Access) -- (2)
+>              H (Named_Access => My_Var'Access) -- (3)
+>             )
+>         );
+>
+> With renaming semantics, all of the above are legal, and the run-time
+> accessibility check for (2) inside G uses the level of Var.
+> (Well, (3) is legal only if the type is at the same level as Var.)
+>
+> With constant semantics, (1) is illegal because it's trying to pass a
+> constant as a 'out' parameter.
+
+It would be plain horrible for (1) to be legal in my opinion.
+very confusing, these should not be lvalues, I think it is better perhaps to
+stick with plain value copying if this sort of thing is going to become legal,
+UGH!
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  10:39 AM
+
+I think "IN" parameter semantics gives you what you want.  No copying allowed
+for by-reference types, including all controlled, task, protected, etc. Copying
+allowed but not required for other composites (but no adjust/finalize possible,
+since those are all by-reference types).  Copying required for elementary.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  10:46 AM
+
+That's what I assumed was meant here, I was shocked by Bob's example :-)
+
+The above sounds exactly right to me
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  10:49 AM
+
+I am a bit concerned that the IN parameter semantics for the with-expression
+declarations will considerably complicate the implementation, since then there
+is no simple transcription to existing declarations, and I don't quite see how
+to implement it :-(
+
+We rely on the backend for much of the semantics of parameter passing, and it is
+only triggered by parameters.
+
+Tuck, do you have some implementation model in mind, in terms of current
+semantics?
+
+With copying, this is essentially syntactic sugar, as I illustrated in my
+proposed implementation.
+
+With renaming using IN parameter semantics, I don't see a simple implementation
+model.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  11:00 AM
+
+> That's what I assumed was meant here, I was shocked by Bob's example
+> :-)
+>
+> The above sounds exactly right to me
+
+There are three proposed semantics: renaming, constant, and IN param.
+My previous e-mail was misleading, because it only considered the first two.  In
+my example, with IN param semantics:
+
+>     X : constant Integer :=
+>         (with My_Var => Var do
+>             (F (Out_Param => My_Var) -- (1)
+>              G (Access_Param => My_Var'Access) -- (2)
+>              H (Named_Access => My_Var'Access) -- (3)
+>             )
+>         );
+
+all three lines would be illegal.  But if we change the type to a by-reference
+type, (2) and (3) would be legal, but only if it's access-to-constant.
+
+I suppose that's not so horrible after all.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  11:14 AM
+
+I would think for composite types, renaming is equivalent to "IN" parameter
+dynamic semantics, while for elementary types, copying does what you want.
+
+The constant-ness is a static-semantics- only concern, and shouldn't affect the
+run-time model.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 4, 2010  11:21 AM
+
+Maybe we should avoid saying that there is some kind of similarity with "IN"
+parameters here, because for actual parameter passing the determination of
+whether to pass something by copy or by reference is shared between front-end
+and back-end, and it would be pointless (or plain impossible) to try to
+reproduce this in with-expressions. It should be enough to say that there is
+copying for elementary types, renaming for by reference-types, and
+implementation-defined behavior for the rest.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  11:25 AM
+
+> I suppose that's not so horrible after all.
+
+And as per discussion with Ed, we don't require equivalence with IN parameter handling here, IN parameter semantics means
+
+a) for by copy types, do a normal constant declaration
+b) for by reference types, do a renaming
+c) for all others, choose a) or b) as you please
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  1:37 PM
+
+> And as per discussion with Ed, we don't require equivalence with IN
+> parameter handling here, IN parameter semantics means
+>
+> a) for by copy types, do a normal constant declaration
+> b) for by reference types, do a renaming
+> c) for all others, choose a) or b) as you please
+
+I'm puzzled by Ed's comment, and your echo of it above.
+Yes, the above is the semantics of IN params.
+Tuck is suggesting that these new 'with' thingies have the same semantics.  How
+are you and Ed suggesting that they differ from IN params?
+
+Maybe "don't require" above is a typo for "do require"?
+
+By the way, how far do we take the analogy with IN params?
+Besides by-copy vs. by-ref as discussed above, there are other issues.  For
+example:
+
+    X : access T;
+    Y : String := (with My_X => X do "Hello");
+
+Is My_X an access parameter, with dynamic accessibility level?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  2:03 PM
+
+Saying something is EQUIVALENT to the handling of IN parameters to me implies
+that an implementation handle them equivalently, which we do not intend to do.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 4, 2010  2:31 PM
+
+> Is My_X an access parameter, with dynamic accessibility level?
+
+Robert was concerned that "equivalent" was meant to be taken literally, in which
+case it was a mystery how to achieve this, given that much parameter passing
+decisions are made by the back-end in a target-specific way, taking alignment
+into account, etc.  If "it's just like IN parameters" is meant metaphorically,
+there is no problem.  we know what is really by reference and what is really by
+copy, and the rest is up to the implementation.
+
+Concerning My_X above, I would hope that there are no additional accessibility
+issues that arise. (Do we need another example of the unholy nature of anonymous
+access types?)
+
+****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 4, 2010  2:56 PM
+
+> Is My_X an access parameter, with dynamic accessibility level?
+
+If we want to avoid having parameterized expressions involve implicit type
+declarations, then it seems that the type of the parameter must be that of the
+actual expression, even if that type is anonymous.
+
+This looks like an area where getting the definition right may require some
+care.
+
+====
+
+The nominal subtype of one of these parameters also needs to be similarly
+defined; this can make a difference if the parameter governs a case expression.
+
+====
+
+Should these "actual parameter" expressions be subject to the same "is expected
+to be of any type" name resolution rule as the operand of a type conversion? I
+think that is needed if we want to go with a "determine the parameter types
+before looking at the rest of the expression" model for name resolution, which
+seems desirable.
+
+====
+
+Can a parameterized expression be static?
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 4, 2010  3:15 PM
+
+>Should these "actual parameter" expressions be subject to the same
+>"is expected to be of any type" name resolution rule
+>as the operand of a type conversion? I think that is needed if
+>we want to go with a "determine the parameter types before
+>looking at the rest of the expression" model for name resolution,
+>which seems desirable.
+
+Each one of these [declarations? bindings?]  must be a complete context, so the
+resolution rule  for each expression must be the same as that of  the expression
+of a conversion.
+
+====
+
+>Can a parameterized expression be static?
+
+If all the constituents are static, I don't see why not.
+
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 4, 2010  3:36 PM
+
+...
+> ====
+>
+> Can a parameterized expression be static?
+
+Uncle!
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Tuesday, May 4, 2010  3:36 PM
+
+> Should these "actual parameter" expressions be subject to the same "is
+> expected to be of any type" name resolution rule as the operand of a
+> type conversion? I think that is needed if we want to go with a
+> "determine the parameter types before looking at the rest of the
+> expression" model for name resolution, which seems desirable.
+
+Yes, I think they should be handled like type conversion arguments.
+Otherwise it seems that resolution will get too complicated.
+
+> ====
+>
+> Can a parameterized expression be static?
+
+I would think so.  Making them nonstatic seems overly restrictive.
+Do you foresee any semantic problem?
+
+****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 4, 2010  3:56 PM
+
+>> Can a parameterized expression be static?
+>
+> I would think so.  Making them nonstatic seems overly restrictive.
+> Do you foresee any semantic problem?
+>
+
+No, just more RM wording that needs to be written.
+
+Getting the accessibility levels right for these guys is another such detail.
+
+And deciding whether these expressions fall into the
+   ok-for-build-in-place
+category (like aggregates, function calls, and (I think) the two forms of
+conditional expressions).
+
+And deciding whether a parameter expression can include a name which denotes an
+earlier parameter, as in
+     (with X => ..., Y => X + 1 do ...)
+.
+
+And deciding whether any applicable index constraint which is imposed on one of
+these guys is recursively imposed on the post-do expression. Same question for
+the expected type. Same question for the "shall resolve to" rule for qualified
+expressions.
+
+Just details that need to be nailed down once we have agreed on the general
+idea.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  4:19 PM
+
+I'd love to see the inside of your brain someday, Steve... ;-)
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 4, 2010  4:22 PM
+
+> And deciding whether a parameter expression can include a name which
+> denotes an earlier parameter, as in
+>    (with X => ..., Y => X + 1 do ...)
+
+Should work like other declarations: these are not formal parameters, they are
+local bindings, elaborated  sequentially. If such an expression appears in a
+renaming, the visibility of these bindings should be as that of local variables
+of a subprogram, right?
+
+function Check (X : integer := 15) renames (with X => 10 do  X**3)
+
+the inner X hides the outer one.  We can still write Check.X to retrieve the
+outer one.
+
+****************************************************************
+
+From: Yannick Moy
+Date: Tuesday, May 4, 2010  3:43 PM
+
+> I fully agree with this position, can we agree on this tentative
+> syntax as the best choice *if* we put them in
+>
+>    WITH_EXPRESSION ::= (with DECL {, DECL} in EXPRESSION)
+>
+>     DECL ::=  IDENTIFIER = EXPRESSION
+>
+> with parens being omittable as for conditional expressions?
+>
+> I think calling these WITH-expressions is a reasonable choice.
+
+As various examples by Robert have shown, even after everybody agreed on "do"
+instead of "in", "in" sticks as being more natural.
+
+"do" has a more natural inclination to indicate operations rather than
+expressions.
+
+so what about parentheses arount the DECLs above as in:
+
+   with (X => 3 * Y, Z => 2 + T) in X - Z
+
+****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 4, 2010  4:05 PM
+
+> "do" has a more natural inclination to indicate operations rather than
+> expressions.
+
+
+I agree, but "in" is already used in expression syntax whereas "do" is not.
+
+Would you prefer "for"?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  4:25 PM
+
+> I agree, but "in" is already used in expression syntax whereas "do" is
+> not.
+>
+> Would you prefer "for"?
+
+For seems bizarre to me.
+I can live with do
+
+****************************************************************
+
+From: Yannick Moy
+Date: Tuesday, May 4, 2010  4:34 PM
+
+> For seems bizarre to me.
+> I can live with do
+
+What is the problem of having "in" already in expression syntax?
+If we agree to parenthesize the bindings (which make them look more like
+parameters or aggregate syntax), then there is no ambiguity.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, May 4, 2010  4:43 PM
+
+I don't much like parenthesizing the declarations, but let's see what others
+think, it is true that
+
+   (with (....) in blabla)
+
+is unambiguous, do we still need the outer parens in this case?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 4, 2010  5:01 PM
+
+I prefer (with ... do ...).  The extra
+parentheses doesn't help readability
+in my view, and we will get used to "do"
+pretty quickly, even if it isn't
+the most natural on first exposure.
+
+Omitting the parens around the whole construct seems like a non-starter in my
+book, now that we have adopted parens around if- and case- expressions.
+
+****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 4, 2010  5:16 PM
+
+> What is the problem of having "in" already in expression syntax?
+It is a matter of human readability, not formal ambiguity.
+
+> If we agree to parenthesize the bindings (which make them look more
+> like parameters or aggregate syntax), then there is no ambiguity.
+>
+True, but we are talking about readability, which is subjective.
+
+I don't think
+
+    Flag := (use X => 34, Y => F (G) for Foo (X, Y, Bar (X)) = Y);
+
+looks bizarre, but it sounds like most prefer "with" and "do".
+I think I could live with any of the 6 "with/use" x "for/in/do"
+alternatives.
+
+I agree with Tuck that we want consistency with conditional expressions with
+regard to parens.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 4, 2010  5:39 PM
+
+...
+> It is often also a much more convenient form for local abstraction.
+> Consider something like
+>
+>       declare
+>          A : Float := Factor * Adjustment;
+>       begin
+>          return A * A + A;
+>       end;
+>
+> This reads fine and is much shorter:
+>
+>       return (with A = Factor * Adjustment do A * A + A);
+
+Right. My point was that I've rarely seen the need for the first form, so
+necessarily I wouldn't have seen the need for the second form. But I was less
+concerned about my personal thinking than the bigger picture.
+
+> > While that's probably a useful goal, I don't see how that's going to
+> > help us sell this to the Ada community at large.
+>
+> I think no changes we do to the language are specifically much help in
+> selling to the Ada community, other than to show a general activity in
+> keeping Ada current and showing continued interest. After all our (our
+> = AdaCore for this
+> sentence) major competitor, Greenhills, has decided it is not even
+> worth investing in Ada 2005, let alone Ada 2012.
+
+I think you missed my point (probably my fault). The "Ada Community" (by that I
+mean the people who tend to be involved in SIGAda, comp.lang.ada, the ARG, etc.
+rather than the run-of-the-mill programmer) tends to have strong ideas about
+what makes Ada great. When we (the ARG) adds new features, we need to do so in a
+way that does not run counter to what makes Ada great (at least for the majority
+of the community) -- or we need to be able to sell the feature as a clear
+improvement.
+
+I would agree that not much of anything would matter to people who aren't
+currently using Ada extensively. But I don't want to alienate the current
+customers (the old saw is that is a lot easier to retain an existing customer
+than it is to get a new one).
+
+...
+> > Some people (not on the ARG!)
+> > already have objected to conditional expressions, and this of course
+> > is much more strongly in the same direction.
+>
+> Ah, the infamous "some people". Who are these people? Do they know
+> anything? And what specifically is their objection to conditional
+> expressions (which are by the way a VERY nice improvement, we have
+> redone our run-time library with judicious but fairly extensive use of
+> conditional expressions, and it is a big improvement).
+
+Sorry. I recall reading somewhere (probably comp.lang.ada) various gripes about
+conditional expressions as implemented in GNAT. I don't remember the details in
+much detail because I was strongly convinced as you are that conditional
+expressions are a good thing.
+
+But when it is less clear that a feature is a good thing (as in this case),
+those gripes could start becoming significant. In that case, I think we need to
+have a case ready as to why the feature is significant.
+
+> > After all, this is a fairly complex feature to define and implement
+> > (we'll need to make sure that we don't make the same mistake we made
+> > with extended returns, for instance, so that the newly defined
+> > identifier is actually visible after the "do"). We will
+> need a decent justification for it.
+>
+> Not so hard to implement, maybe a day or two's work for us, and as for
+> other compilers, we don't even see them implementing critical 2005
+> features yet, so I can't get to excited about
+> difficulty-of-implementation arguments
+
+The effort for us would be very dependent on whether the declarations are
+renames or objects. Since we have a fairly strong wall between expressions and
+the rest of the semantics, we would have to move object allocation from one side
+to the other.
+
+In any case, it's not trivial; as you note, it can't be modeled with any
+existing Ada feature.
+
+> > I admit that I'm a bit dubious about the need for constants. I've
+> > been racking my brain and can't remember a case where I wanted a
+> > constant to use in a single expression (variables are different, see
+> > below). I realize that conditional expressions (both types) could
+> > potentially make expressions larger, but I've been hoping that the
+> > provision of expression functions would tend to limit the size of
+> > expressions -- if they get too large, it is better to create an
+> > abstraction to represent parts and break them up.
+>
+> That's strage to me, I guess it's just a frame of mind, have you ever
+> done significant programming in a functional language?
+
+No. My only use of a functional language was in a programming language survey
+course at the University of Wisconsin. I've never quite been able to understand
+the value of such languages for real programming (it's easy to write simple
+examples in them, but real systems are much more complex). In any case, I've
+never had an implementation that would be efficient enough (much less of a
+concern today, of course)
+
+> > I do strongly prefer the "=>" notation, as we definitely do not want
+> > these to look like declarations. Otherwise, we'd have endless
+> > arguments about why variables aren't allowed (or whether they should
+> > be allowed). The only cases I can think of where I've used local
+> > objects for a single expression is to discard unnecessary
+> in out and out parameters.
+>
+> Why would you "discard" unnecessary parameters, why not just ignore
+> them, confused ....
+
+If they are "in out" or "out" parameters, you have give them in a call (they
+can't be defaulted). That means that you need some value to put them into, and
+that value might as well have a very local scope. So I write things like:
+
+    declare
+        Unused : Handle;
+    begin
+        Replace_Window (Window, New_Window => Pretty, Old_Window => Unused);
+    end;
+
+I could imagine wanting to do something like that for functions as well,
+especially the ones in C APIs (where most of the results are in parameters, the
+function result being just a status code).
+
+P.S. I'm just starting to read the mail after spending much of the day on a home
+plumbing problem. Sorry about being so far behind.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 4, 2010  6:26 PM
+
+Reading these in quick succession, I'm struck by:
+
+Robert Dewar writes:
+> > After all, this is a fairly complex feature to define and implement
+> > (we'll need to make sure that we don't make the same mistake we made
+> > with extended returns, for instance, so that the newly defined
+> > identifier is actually visible after the "do"). We will
+> > need a decent justification for it.
+
+...
+> As for difficulty-of-definition, I don't see a problem, it is
+> certainly nothing like the extended return (which was a HUGE pain in
+> the neck, and for me a case where the implementation and definition
+> efforts were unreasonably large. For me the second most glaring
+> example of a mismatch between effort and value -- the first being leap
+> seconds, about which don't get me started!)
+
+Steve Baird writes:
+
+> Can a parameterized expression be static?
+...
+>Getting the accessibility levels right for these guys is another such
+detail.
+>
+>And deciding whether these expressions fall into the
+>   ok-for-build-in-place
+>category (like aggregates, function calls, and (I think) the two forms
+>of conditional expressions).
+>
+>And deciding whether a parameter expression can include a name which
+denotes an earlier parameter, as in
+>     (with X => ..., Y => X + 1 do ...) .
+>
+>And deciding whether any applicable index constraint which is imposed
+>on one of these guys is recursively imposed on the post-do
+>expression. Same question for the expected type.
+>Same question for the "shall resolve to" rule for qualified expressions.
+>
+>Just details that need to be nailed down once we have agreed on the
+>general idea.
+
+Robert, are you still sure that the definition is not a problem?? ;-)
+
+I was thinking about a few of the issues that Steve pointed out (particularly
+the scope and nominal subtype of the definition), and was pretty sure that Steve
+would fine a bunch more. Probably none of them are hard by themselves, but the
+sheer number makes this quite a bit of work for the language definition.
+
+Keep in mind that we still haven't been able to quite settle on the details of
+resolution for conditional_expressions and we've been working on it for a couple
+of years; this is more complex than that feature and we've only just scratched
+the surface.
+
+****************************************************************
+
+From: John Barnes
+Date: Wednesday, May 5, 2010  1:54 AM
+
+Although I agree it is very interesting and I too had a brief flirtation with
+Algol 68 -- But  why are we discussing this topic at all? I thought we had
+agreed that no further topics were to be considered for Ada 2012. Maybe we need
+another address for old boys chatter.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, May 5, 2010  7:20 AM
+
+Well the discussion is valuable whether or not this feature goes into the
+official Ada 2012 standard, because it is likely that GNAT will implement it in
+any case, and it is useful to get input on what to implement. A useful
+perspective here is that if you look at the Ada 2012 standard, it has two
+impacts:
+
+1. Show everyone, including Ada enthusiasts and Ada serious users, that Ada is
+   alive and well and still being worked on.
+
+2. Provide a template for enhancements to GNAT
+
+Right now, no other implementation has touched Ada 2005, let alone 2012, so I am
+afraid that the desired effect of having all Ada implementations include the Ada
+2012 extensions looks out of reach. This is unfortunate, but not much can be
+done about it.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, May 5, 2010  7:46 AM
+
+> Omitting the parens around the whole construct seems like a
+> non-starter in my book, now that we have adopted parens around if- and
+> case- expressions.
+
+Do we still allow omitting them when they are there anyway, e.g. in a pragma
+argument.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, May 5, 2010  7:47 AM
+
+> True, but we are talking about readability, which is subjective.
+>
+> I don't think
+>
+>     Flag := (use X => 34, Y => F (G) for Foo (X, Y, Bar (X)) = Y);
+>
+> looks bizarre, but it sounds like most prefer "with" and "do".
+> I think I could live with any of the 6 "with/use" x "for/in/do"
+> alternatives.
+>
+> I agree with Tuck that we want consistency with conditional
+> expressions with regard to parens.
+
+It is a pity we can't use IN, what if we said that the expressions in the
+declarations were simple expressions. We are losing a valuable use of IN here
+for a very marginal case :-(
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, May 5, 2010  7:49 AM
+
+> ...
+>> It is often also a much more convenient form for local abstraction.
+>> Consider something like
+>>
+>>       declare
+>>          A : Float := Factor * Adjustment;
+>>       begin
+>>          return A * A + A;
+>>       end;
+>>
+>> This reads fine and is much shorter:
+>>
+>>       return (with A = Factor * Adjustment do A * A + A);
+>
+> Right. My point was that I've rarely seen the need for the first form
+
+I find that a truly surprising comment, what would you do in this case?
+
+a) duplicate code? UGH
+
+b) declare A more globally?, also for me UGH, why? because if A is more globally
+   declared, you can't tell whether the value after this local use is going to
+   be used.
+
+I think that it is a fundamental principle of ANY block structured language to
+declare things as locally as possible.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 5, 2010  1:39 PM
+
+> Do we still allow omitting them when they are there anyway, e.g. in a
+> pragma argument.
+
+I would presume we'd use the same rules/syntax as we do for conditional
+expressions (if and case). It would be annoying to have different rules for
+every kind of expression (which is way we ended up with a fairly conservative
+rule about omitting them -- the case expressions would get ambiguous if the
+parens are omitted after "=>", as their syntax contains "=>").
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 5, 2010  2:00 PM
+
+> >> Consider something like
+> >>
+> >>       declare
+> >>          A : Float := Factor * Adjustment;
+> >>       begin
+> >>          return A * A + A;
+> >>       end;
+> >>
+> >> This reads fine and is much shorter:
+> >>
+> >>       return (with A = Factor * Adjustment do A * A + A);
+> >
+> > Right. My point was that I've rarely seen the need for the
+> first form
+>
+> I find that a truly surprising comment, what would you do in this
+> case?
+>
+> a) duplicate code? UGH
+>
+> b) declare A more globally?, also for me UGH, why? because if A is
+> more globally declared, you can't tell whether the value after this
+> local use is going to be used.
+>
+> I think that it is a fundamental principle of ANY block structured
+> language to declare things as locally as possible.
+
+Almost certainly "A". I try to only add abstraction when it really is
+meaningful. Adding a declaration "A" in this example is *not* meaningful. (And I
+admit I'm not good at recognizing places where abstraction can be added.) I
+would use a block as you show here if I did add this declaration (although I'd
+probably first look to see if there is an existing block nearby that I could
+use, as otherwise the indentation gets out of hand quickly - having to scroll
+sideways when browsing through code is really annoying).
+
+Indeed, I naturally simply write the entire body of whatever I'm doing as one
+straight chunk of code. Only if I recognize that control flow is requiring
+duplicate code will I make a subprogram, which I make nested (in a block if
+possible) unless it is clearly useful abstraction. This is essentially code
+refactoring on the fly. And the code in question needs to be significant before
+I'll do that.
+
+As a consequence, renames are rare in my code, and constants aren't particularly
+common (most are for binding function results). I don't think such things add to
+readability in general, as they make it harder to see what is really being
+calculated. (There are exceptions, of course, but if I can't give it a
+meaningful name, I won't do it. And meaningful names are very hard...)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 5, 2010  2:54 PM
+
+> Although I agree it is very interesting and I too had a brief
+> flirtation with Algol 68 -- But  why are we discussing this topic at
+> all? I thought we had agreed that no further topics were to be
+> considered for Ada 2012. Maybe we need another address for old boys
+> chatter.
+
+Well, we have the "expression function" proposal open. If this idea is
+considered a critical part of that proposal, then we could add it as part of
+that. I suspect that there are at least some people who would agree with that.
+
+Anyway, what we are accepting as Amendments (and as Binding Interpretations for
+that matter) are problem statements, not necessarily solutions. The ARG is in
+the solution business, after all. That means we're not accepting any more
+problems to solve in the Amendment, not that we aren't accepting alternate
+solutions to solve the problems that we already are attempting to solve. It
+would be silly to restrict ourselves only to solutions that we've already
+considered, because that would prevent tweaking that would make the features
+better. After all, we've split several existing AIs since we've stopped
+considering new AIs -- we surely can consider the new split AIs. And surely we
+can do that here if we as a group feel it is important.
+
+What we we're not allowing is the introduction of new problems. For instance,
+while I would like to see object versions of the attributes Image, Succ, Pred,
+and probably Pos, we'd have to figure out a way to bend one of the existing
+problems to justify that inclusion. That's probably too hard to justify for a
+nice-to-have feature (although I suspect we could repurpose AI-187 for this
+purpose if we really wanted to).
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Wednesday, May 5, 2010  3:42 PM
+
+> It is a pity we can't use IN, what if we said that the expressions in
+> the declarations were simple expressions.
+> We are losing a valuable use of IN here for a very marginal case :-(
+
+Sounds reasonable to require simple_expressions.  If you need an expression involving membership/relational/logical ops (in front of 'in') then you just have to parenthesize.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Monday, May 24, 2010  7:29 AM
+
+I just noticed that a null procedure declaration cannot be used "as body".
+
+Allowing this looks like a very small change for a very small benefit.
+Do you think it is worth an AI?
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 25, 2010  1:49 PM
+
+Not really.  Null procedures allow you to have package specs without bodies,
+little point in then giving  you means to be forced to have them!
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 25, 2010  2:01 PM
+
+The null procedure is primarily for interfaces, and those don't even need a
+private part much less a body, so it doesn't seem worth adding complexity.
+Renaming-as-body and body-as-spec are nasty enough as it is.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 25, 2010  2:25 PM
+
+Normally I would say it isn't worth it, but the proposed syntax for
+parameterized expressions will definitely be able to be used as a body, and it
+is quite similar.
+
+    parameterized_expression ::= function_specification is (expression);
+    null_procedure_declaration ::= procedure_specification is null;
+
+That makes it likely that it will seem odd that you can't use it as shorthand
+for a body. So perhaps we ought to consider it as part of the parameterized
+expressions AI.
+
+(I don't think we want to be opening any new AIs for nice-to-haves at this
+point, so I don't think we would make any changes if a stand-alone AI is
+needed.)
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 25, 2010  2:55 PM
+
+Seeing this juxtaposition makes me think that another part of this AI ought to
+be allowing "(expression)" as a default for a formal function, in the same way
+that we allow "null" as a default for a formal procedure.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 25, 2010  3:21 PM
+
+I agree.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, May 25, 2010  3:20 PM
+
+>     parameterized_expression ::= function_specification is (expression);
+>     null_procedure_declaration ::= procedure_specification is null;
+>
+> That makes it likely that it will seem odd that you can't use it as
+> shorthand for a body. So perhaps we ought to consider it as part of
+> the parameterized expressions AI.
+
+I was going to say "no", but Randy's argument convinced me to say "yes".
+
+It's one of those cost/benefit = the ratio of two infinitesimals, so it's hard to get excited either way.
+
+I remember trying to use "is null" as a body once, and was surprised it's not allowed.  Once in my life.
+
+> (I don't think we want to be opening any new AIs for nice-to-haves at
+> this point, so I don't think we would make any changes if a
+> stand-alone AI is
+> needed.)
+
+I agree.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, October 20, 2010  10:14 PM
+
+Following is a first attempt at the wording for expression functions. I tried to
+copy the wording for null procedures and default_expressions as much as
+possible: that made it easier to see what needed to be done.
+
+Note that I changed the name from "parameterized expressions" to "expression
+functions" as the wording seems to make more sense with the latter: it's similar
+to a null procedure, it can complete a subprogram, it's called with a function
+call, etc. If it didn't contain the word "function", I suspect that quite a bit
+of wording would have to be changed to add "parameterized expressions" as a
+possible type of subprogram, callable entity, etc. I cheated a bit and called
+the expression a "parameterized_expression", so we don't lose that term
+completely.
+
+Comments welcome.
+
+P.S. If we really want to do something with a Let expression/block
+expression/with expression or whatever else you want to call it, I recommend
+that be a separate AI. This one is complicated enough...
+
+[This is version /03 of the AI - Editor.]
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, October 20, 2010  10:53 PM
+
+You didn't quite complete the cut and paste job.
+"null_procedure_declaration" appears several places where I suspect you meant
+"expression_function_declaration." Also, there are quite a few places where "a"
+should be "an" because the construct name now starts with a vowel. I have
+extracted most of the problematic sentences below.
+
+Otherwise, looks good.
+
+> A expression function can define the body of a function, even in a
+> package
+
+> [Note: The parens are needed to clearly (?) separate a expression
+> function
+
+> A expression function can be used as a declaration or as the
+> completion of
+
+> null_procedure_declaration (see 6.7){, or a
+> expression_function_declaration (see 6.8)}.
+
+> Legality Rules
+>
+> A null_procedure_declaration need not be the completion of a previous
+> declaration, but if a null_procedure_declaration is a completion, it
+> shall be the completion of a subprogram_declaration or
+> generic_subprogram_declaration.
+> The profile of a null_procedure_declaration that completes a
+> declaration shall conform fully to that of the declaration.
+>
+> [Editor's note: This is mostly copied from the text for subprogram
+> bodies, some redundancy removed.]
+>
+> Modify 6.7(3/2):
+>
+> A null_procedure_declaration declares a null procedure. A completion
+> is not allowed for a null_procedure_declaration{, however a
+> null_procedure_declaration can complete a previous declaration}.
+>
+> Modify 6.7(5/2):
+>
+> The elaboration of a null_procedure_declaration has no {other} effect
+> {than to establish that the expression function can be called without
+> failing the Elaboration_Check}.
+
+> The profile of a expression_function_declaration that completes a
+
+> The elaboration of a expression_function_declaration has no other
+> effect
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Thursday, October 21, 2010  2:16 AM
+
+>    expression_function ::=
+>       [overriding_indicator]
+>       function_specification is (<*parameterized_*expression>);
+>
+> [Note: The parens are needed to clearly (?) separate a expression
+> function from the start of a normal function body. Perhaps it would be
+> better to use a keyword somewhere to make it crystal-clear.]
+>
+<asbestos_suit_on>
+what about:
+   function_specification := (<*parameterized_*expression>);
+</asbestos_suit_on>
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, October 21, 2010  8:00 AM
+
+I much prefer the IS, the := here seems most irregular, and implies an
+assignment to the entity on the left, which is not what is going on here at all.
+
+Are we definite about the terminology change, if so I will just go ahead and
+implement that change in GNAT.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, October 21, 2010  9:48 AM
+
+>   function_specification := (<*parameterized_*expression>);
+
+Uggggh. ;-)
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, October 21, 2010  12:07 PM
+
+> !proposal
+> ... given anywhere in the same package (if the declaration is a package).
+     if the declaration is *in* a package
+
+====
+
+Clearly
+
+     Global_Task : Some_Task_Type;
+
+     function F return Some_Task_Type is (Global_Task);
+
+should be illegal. What wording prevents this?
+
+====
+
+Is the convention for one of these guys defined in the same way as the
+convention for a null procedure?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 21, 2010  1:18 PM
+
+...
+> Are we definite about the terminology change, if so I will just go
+> ahead and implement that change in GNAT.
+
+I think so, but you may want to wait until after the meeting next week to be
+sure.
+
+Bob wanted to call these "expression functions" from the beginning, and others
+did so intermittently in the e-mail. I was going to use "parameterized
+expressions" (which explains the use better), but that is not clearly a type of
+subprogram, while <something> functions clearly is. I didn't want to have to go
+all over the standard looking for subprogram and function and checking to see if
+parameterized expressions needed to be added; that sounds error-prone at best.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 21, 2010  1:22 PM
+
+> Clearly
+>
+>      Global_Task : Some_Task_Type;
+>
+>      function F return Some_Task_Type is (Global_Task);
+>
+> should be illegal. What wording prevents this?
+
+I checked all of the legality rules for return statements, but this one isn't
+there, it's in 7.5. So
+
+* the *parameterized_*expression of an expression_function_declaration (see 6.8)
+
+needs to be added to 7.5 (after 2.8/2, I think).
+
+> ====
+>
+> Is the convention for one of these guys defined in the same way as the
+> convention for a null procedure?
+
+Yes: there doesn't seem to be any definition for the convention of null
+procedures. :-) It's surely not in 6.7.
+
+Is there any such definition that I've missed? If so, it needs to be updated to
+add expression_functions. If not, well then you have an action item.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, October 21, 2010  1:47 PM
+
+>> Is the convention for one of these guys defined in the same way as
+>> the convention for a null procedure?
+>
+> Yes: there doesn't seem to be any definition for the convention of
+> null procedures. :-) It's surely not in 6.7.
+>
+
+We have to decide what we want.
+
+Nothing needs to be done if we want Ada (6.3.1(3), at least when not superceded
+by 6.3.1(13.2/1)).
+
+This would mean that you can take 'Access of one of these guys.
+
+If we decide that that is an excessive implementation burden (e.g., because some
+implementations might have to generate wrappers), then we could add these guys
+to the 6.3.1 list of things that get convention Intrinsic.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 21, 2010  2:01 PM
+
+> This would mean that you can take 'Access of one of these guys.
+>
+> If we decide that that is an excessive implementation burden (e.g.,
+> because some implementations might have to generate wrappers), then we
+> could add these guys to the 6.3.1 list of things that get convention
+> Intrinsic.
+
+Humm. You have to be able to generate wrappers for expression functions: for
+instance, if they override a dispatching call (you'll need a wrapper to use in
+the tag, at a minimum), if they are given as a completion in the body of package
+(they'll need to be a real body in that case), possibly if passed in an
+instance. So the burden to do that for 'Access isn't that high.
+
+OTOH, it's annoying to have to do that for these when declared in a
+specification (otherwise those can always be inlined).
+
+But all-in-all, I would think that the complexity of defining precisely when you
+aren't allowed to take 'Access would be as bad as just making it work. So I lean
+to the status quo here. I can be convinced otherwise.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, October 21, 2010  2:03 PM
+
+All dispatching operations need to be Ada, I believe.
+For non-dispatching operations, I would vote for Intrinsic, though for me it
+isn't a terribly big deal either way. This applies to both expression functions
+and null procedures.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, October 21, 2010  2:10 PM
+
+> Humm. You have to be able to generate wrappers for expression
+> functions: for instance, if they override a dispatching call (you'll
+> need a wrapper to use in the tag, at a minimum), if they are given as
+> a completion in the body of package (they'll need to be a real body in
+> that case), possibly if passed in an instance. So the burden to do that for 'Access isn't that high.
+
+Agreed.
+
+> OTOH, it's annoying to have to do that for these when declared in a
+> specification (otherwise those can always be inlined).
+
+Note that with conditional expressions it's possible for expression functions to
+be recursive, which will make it rather hard to inline calls to them!
+
+> But all-in-all, I would think that the complexity of defining
+> precisely when you aren't allowed to take 'Access would be as bad as just making it work.
+> So I lean to the status quo here. I can be convinced otherwise.
+
+Convention Ada makes sense.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, October 21, 2010  2:58 PM
+
+> Following is a first attempt at the wording for expression functions.
+> I tried to copy the wording for null procedures and
+> default_expressions as much as possible: that made it easier to see what needed to be done.
+
+Looks good to me.  Some typos and whatnot marked below.
+
+> [Note: The parens are needed to clearly (?) separate a expression
+> function
+
+"a" --> "an"
+
+> from the start of a normal function body. Perhaps it would be better
+> to use a keyword somewhere to make it crystal-clear.]
+
+The parens look OK to me, I guess.
+
+> The expected type of the parameterized_expression is that of the
+> return subtype of the function_specification.
+>
+> Within the parameterized_expression, the names of the parameters of
+> the function_specification are visible.
+
+directly visible
+
+> The dynamic semantics are the same as a function whose body contains
+> nothing but "return parameterized_expression".
+>
+> A expression function can be used as a declaration or as the
+> completion of
+
+"A" --> "An"
+
+> a function specification. If used as a completion, the completion can
+> be given anywhere in the same package (if the declaration is a package).
+
+But surely not before the declaration!
+
+> Specifically,
+> expression functions in a private part can complete function
+> declarations from the visible part.
+>
+> Freezing: The renamed expression would freeze as does a default expression.
+
+"renamed" --> "parameterized"
+
+> That
+> is, freezing would only be performed at the point of a call of the
+> function, with the expression essentially in-lined at that point. (Of
+> course, if that
+
+"in-lined" --> "inlined"
+
+> call
+> is in a default expression, the freezing would be deferred again.)
+>
+> !wording
+
+> Legality Rules
+>
+> A null_procedure_declaration need not be the completion of a previous
+> declaration, but if a null_procedure_declaration is a completion, it
+> shall be the completion of a subprogram_declaration or
+> generic_subprogram_declaration.
+> The profile of a null_procedure_declaration that completes a
+> declaration shall conform fully to that of the declaration.
+
+Heh?  What's this about null procs?
+
+> [Editor's note: This is mostly copied from the text for subprogram
+> bodies, some redundancy removed.]
+
+> !discussion
+
+> We did "borrow" the parameterized expression name to mean the actual
+> expression of an expression function. This simplifies some of the
+> wording and re-enforces
+
+"re-enforces" --> "reinforces"
+
+> the usage intent.
+>
+> ---
+>
+> A goal for expression functions is that they represent a subset of the
+> capabilities of null subprograms in terms of the use as subprogram.
+
+That's a strange thing to say.  I mean, null procedures have just about the
+fewest "capabilities" of any feature -- they don't do anything!  Expr functions
+can do lots of things.
+
+So I'm not understanding what you're getting at, here -- could use some
+rewording.
+
+>...If we didn't do that, we would
+> have added another kind of subprogram, whose usages would be subtly
+>different than  the existing kinds. That seems bad.
+>
+> In order to accomplish this, we added the capability of a null
+> subprogram to represent a completion. This is not an important
+> capability, but it increases the consistency of the various kinds of
+> subprogram declaration.
+>
+> ---
+>
+> One could imagine these functions (when visible) to be used in static
+> expressions if the inlined expression would be static. This would
+> definitely allow abstracting expressions that currently are written as
+> a giant single expression because they need to be static. That's
+> something you cannot do now. I didn't add this to proposal in order to
+> keep the proposal simple.
+
+Hmm.  Interesting idea.
+
+> ---
+>
+> It has been suggested to allow expression functions as generic formal
+> subprogram defaults. This would increase the analogy with null procedures.
+>
+> I didn't include this for three reasons:
+> (1) The syntax would be very close to the existing default_name syntax.
+> Adding
+> or removing parens would change the semantics substantially.
+> (2) This would probably require explicitly creating a body at the
+> point of the instantiation. So the implementation effort would be
+> substantially increased.
+> (3) We're not likely to make the analogy with null procedures complete
+> (we would need the next item as well), so there is going to be an
+> inconsistency somewhere.
+>
+> Therefore, I stuck with the simpler proposal.
+>
+> ---
+> An additional idea would be to allow this as a primitive subprogram of
+> an interface. If we did that, we would get the benefit of the identity
+> function idea (see AI05-0140-1) without adding anything special
+> specifically for that case.
+> The expression would have to be included in the 8.3 homograph matching
+> rules, probably by borrowing the rules for full conformance of
+> expressions.
+> That would be necessary to deal with the Steve Baird problem for
+> diamond inheritance with interfaces (that was the primary reason that
+> AI05-0140-1 was scuttled).
+
+Steve Baird didn't invent the diamond inheritance problem.
+Or is there a specific diamond inheritance sub-problem that Steve has talked
+about?
+
+Anyway, I can't see how interfaces can have primitive subprograms that do stuff,
+here or in AI05-0140-1 -- otherwise they aren't interfaces, but have grown into
+full multiple inheritance.
+
+> Including both this and the formal subprogram default would make this
+> completely similar to null procedures.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, October 21, 2010  3:01 PM
+
+> Convention Ada makes sense.
+
+Sounds good as a general principle, overridden in corner cases by 6.3.1(13.2/1).
+
+I think this means no wording changes in this area are needed,
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, October 21, 2010  3:30 PM
+
+> ...
+>> Are we definite about the terminology change, if so I will just go
+>> ahead and implement that change in GNAT.
+>
+> I think so, but you may want to wait until after the meeting next week
+> to be sure.
+>
+> Bob wanted to call these "expression functions" from the beginning,
+> and others did so intermittently in the e-mail. I was going to use
+> "parameterized expressions" (which explains the use better), but that
+> is not clearly a type of subprogram, while<something>  functions
+> clearly is. I didn't want to have to go all over the standard looking
+> for subprogram and function and checking to see if parameterized
+> expressions needed to be added; that sounds error-prone at best.
+
+I must say I like the change, even though it's extra effort in the
+implementation to make the change!
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, October 21, 2010  3:35 PM
+
+> Humm. You have to be able to generate wrappers for expression
+> functions: for instance, if they override a dispatching call (you'll
+> need a wrapper to use in the tag, at a minimum), if they are given as
+> a completion in the body of package (they'll need to be a real body in
+> that case), possibly if passed in an instance. So the burden to do that for 'Access isn't that high.
+
+We don't generate wrappers, we just expand expression functions to normal
+functions in any case. They are just syntactic sugar as far as we are concerned.
+
+> OTOH, it's annoying to have to do that for these when declared in a
+> specification (otherwise those can always be inlined).
+
+The normal automatic inlining mechanism takes care of these expanded functions
+pefectly fine
+
+> But all-in-all, I would think that the complexity of defining
+> precisely when you aren't allowed to take 'Access would be as bad as just making it work.
+> So I lean to the status quo here. I can be convinced otherwise.
+
+I would make 'Access work fine (it certainly does in GNAT now!)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, October 21, 2010  3:39 PM
+
+> All dispatching operations need to be Ada, I believe.
+> For non-dispatching operations, I would vote for Intrinsic, though for
+> me it isn't a terribly big deal either way.
+> This applies to both expression functions and null procedures.
+
+We also expand out null procedures unconditionally in GNAT, so it would be extra
+work to forbid access and make them intrinsic. Of course it can be done, but I
+object to doing this on the basis of making things easier for implementations!
+
+It seems an arbitrary and unnecessary restriction to forbid access for either of
+these.
+
+In particuar, you may make a procedure null temporarily, sort of like a stub,
+and it would be annoying not to be able to take 'Access of it.
+
+Similarly, if you decide that you have a function with a trivial body, and you
+want to make it into an expression function now that you have the amazing Ada
+2012 in your hands, it would be annoying to find you can't do this because of an
+arbitrary and peculiar choice for the convention.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 21, 2010  5:55 PM
+
+...
+> > An additional idea would be to allow this as a primitive subprogram
+> > of an interface. If we did that, we would get the benefit of the
+> > identity function idea (see AI05-0140-1) without adding anything
+> > special specifically for that case.
+> > The expression would have to be included in the 8.3 homograph
+> > matching rules, probably by borrowing the rules for full conformance
+> > of expressions.
+> > That would be necessary to deal with the Steve Baird problem for
+> > diamond inheritance with interfaces (that was the primary reason
+> > that
+> > AI05-0140-1 was scuttled).
+>
+> Steve Baird didn't invent the diamond inheritance problem.
+> Or is there a specific diamond inheritance sub-problem that Steve has
+> talked about?
+
+I was specifically referring to the problem that Steve raised during the
+discussion of AI05-0140-1. It's a particular form of diamond inheritance: when
+two expression functions that are subtype conformant are inherited, but the
+expressions are different.
+
+> Anyway, I can't see how interfaces can have primitive subprograms that
+> do stuff, here or in AI05-0140-1 -- otherwise they aren't interfaces,
+> but have grown into full multiple inheritance.
+
+Not at all, these make perfect sense. The interface can't have components, but
+there is lots of other stuff that could make a useful default. For instance,
+it's not unusual to have a query which always returns True (or False or some
+other constant) for most implementations. Or a routine that returns some
+function of its parameters by default. There are examples of that in
+AI05-0140-1.
+
+Moreover, this would work precisely as null procedures do. Those don't cause
+"full multiple inheritance", so I don't see how these would either. The concrete
+implementation could be created when the interface is extended (remember that
+these work like default expressions) - so typically it would be duplicated, not
+shared (same as for null procedures).
+
+The point of Steve's concern is that we would not want to let conflicting
+expression functions to be inherited. That's more complicated than for null
+procedures, as all of those work the same way. But some sort of expression
+conformance would do the trick (or we could just say that they always conflict
+and leave it at that). We already have rules for conflicting subprograms that
+are inherited because the modes could be different, so the problem itself is not
+new.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, October 21, 2010  4:04 PM
+
+> > Humm. You have to be able to generate wrappers for expression
+> > functions: for instance, if they override a dispatching call (you'll
+> > need a wrapper to use in the tag, at a minimum), if they are given
+> > as a completion in the body of package (they'll need to be a real
+> > body in that case), possibly if passed in an instance. So the burden to do that for 'Access isn't that high.
+>
+> We don't generate wrappers, we just expand expression functions to
+> normal functions in any case.
+
+I think that's what Randy means by "wrapper" -- it's an out-of-line piece of code that can be called in the usual way, and can also be inlined when desirable.  And you can take 'Access of it.
+
+>...They are just syntactic sugar as far  as we are concerned.
+> >
+> > OTOH, it's annoying to have to do that for these when declared in a
+> > specification (otherwise those can always be inlined).
+>
+> The normal automatic inlining mechanism takes care of these expanded
+> functions pefectly fine
+> >
+> > But all-in-all, I would think that the complexity of defining
+> > precisely when you aren't allowed to take 'Access would be as bad as just making it work.
+> > So I lean to the status quo here. I can be convinced otherwise.
+>
+> I would make 'Access work fine (it certainly does in GNAT now!)
+
+I agree.
+
+In general adding restrictions to ease implementation is a tricky business --
+you sometimes end up with a more difficult implementation, because it has to
+check the restrictions, but can't take advantage of them.
+
+It's also simplest for programmers to say "these things are just like function
+bodies, except they look different, and they can go in packages specs".  We
+don't want to make the "except..." part longer by adding "and you can't take
+'access, and mumble mumble generic mumble, and...".
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 21, 2010  7:40 PM
+
+...
+> > A goal for expression functions is that they represent a subset of
+> > the capabilities of null subprograms in terms of the use as subprogram.
+>
+> That's a strange thing to say.  I mean, null procedures have just
+> about the fewest "capabilities" of any feature -- they don't do
+> anything!  Expr functions can do lots of things.
+>
+> So I'm not understanding what you're getting at, here -- could use
+> some rewording.
+
+My point is that expression functions can be used in a subset of the places and
+ways that null procedures can, specifically they are called the same way, they
+both can complete subprograms (which is new for null procedures), they can be
+subprogram declarations. Null procedures can also be used as generic formal
+procedure defaults and as the primitives of interfaces. While it would be nice
+if expression functions could be used in those places, that is not important
+functionality and I left it out for Ada 2012 (although it would not surprise me
+if Ada 2020 gained those).
+
+What I didn't want to see is the set of places where you can use normal
+subprograms, abstract subprograms, null procedures, and expression functions all
+end up different. That just adds to the cognitive overhead.
+
+If you have a suggestion for making what I had in mind clearer (preferably
+without the dissertation given here), please suggest it.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, October 21, 2010  7:46 PM
+
+I don't think we should overburden the expression function idea with the diamond
+inheritance problem.
+
+We have enough going on already!
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, October 21, 2010  8:39 PM
+
+> Note that with conditional expressions it's possible for expression
+> functions to be recursive, which will make it rather hard to inline calls to
+> them!
+
+I really don't see why these should be a special case for inlining, you inline
+them if your implementation can do it and feels like it (in GNAT, you get this
+kind of inlining automatically at high optimization levels). If the
+implementation can't inline them, then it won't, end of story! If the
+implementation feels like inlining the recursive case one step it can if it
+likes.
+
+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
+
+****************************************************************
 
-[Editor's note: There are another 80 messages in this thread; ran out of
-time to get them filed. They'll appear soon...]

Questions? Ask the ACAA Technical Agent