CVS difference for ai12s/ai12-0125-3.txt
--- ai12s/ai12-0125-3.txt 2015/10/13 23:32:09 1.1
+++ ai12s/ai12-0125-3.txt 2015/10/13 23:51:06 1.2
@@ -1,14 +1,15 @@
-!standard 5.2.1(0) 15-10-09 AI12-0125-2/02
-!class Amendment 15-10-08
-!status work item 15-10-08
+!standard 5.2.1(0) 15-10-13 AI12-0125-2/03
+!class Amendment 15-10-13
+!status work item 15-10-13
!status received 15-09-22
!priority Low
!difficulty Medium
-!subject Add :+, :-, :*, :/, ...
+!subject Add <<>> as a shorthand for the LHS of an assignment
!summary
-Define :+, :-, ... in terms of "+" operator, "-" operator, etc.
+Define <<>, which can be used in the right-hand side of an assignment
+statement as a shorthand for the name of the left-hand side.
!problem
@@ -25,100 +26,120 @@
!proposal
-We propose to define new *update* operations, ":+", ":-", ":*", ":and", ":or",
-etc. as short hands for assigning a new value of the left hand side to
-be the corresponding operator applied between itself and the right hand
-side.
-
-In this proposal there is no way to explicitly define these operations
--- ined implicitly in terms of the corresponding
-operator, whenever such an operator is defined and directly visible, and
-has a result type that is the same as that of its left-hand operand.
-
-We could envision a separate AI that would allow such operations to be
-defined using an "Update_Operation" aspect on the associated operator
-declaration, such as:
-
- procedure Add_To(Left : in out T; Right : T);
-
- function "+"(Left, Right : T) return T
- with Update_Operation => Add_To;
-
+We define a new symbol, <<>>, which represents a rename of the left-hand
+side of an assignment.
+
!wording
+Add <<>> to Primary in 4.4, with -- See 5.2.1.
+
Add a new subclause:
- 5.2.1 Update Operations
+ 5.2.1 Target name (<<>>) shorthand
- An update_statement assigns a value to a variable computed by
- invoking a binary operator that combines its old value and the value
- of an expression. This *underlying* binary operator is the
- operator identified by the lexical element formed by omitting
- the leading ':' from the update_operation lexical element.
-
- update_statement ::=
- /variable_/name update_operation expression;
- update_operation ::= :+ | :- | :* | :/ | :** | :& |
- :mod | :rem | :and | :or | :xor
-
- Name Resolution Rules
-
- The /variable_/name of an update_statement is expected
- to be of any type. An update_statement is equivalent to a
- local object renaming that declares a unique temporary name
- of the same type as the /variable_/name, to be a renaming of
- the /variable_/name; this is followed by an
+ <<>>, known as the *target name* of an assignment statement,
+ provides a shorthand to avoid repetition of potentially long
+ names in assignment statements.
+
+ Name Resolution Rules
+
+ <<>> has the nominal subtype of the /variable_/name of an
+ assignment_statement.
+
+ Legality Rules
+
+ <<>> shall only appear in the expression of an assignment_statement.
+
+ If <<>> appears in the expression of an assignment_statement S,
+ and the expression contains any function calls other than those
+ to predefined operators or any equality operation of a record
+ type, then the /variable_/name of S shall not denote a
+ subcomponent that depends on discriminants of an object whose
+ nominal subtype is unconstrained, unless the object is known to be
+ constrained.
+
+ AARM Note: This is just the renames legality rule; we allow this
+ in the case that no user-defined routines can be called, as there
+ is no way to change the discriminant in that case. Record equality
+ might have composed a user-defined routine, thus it is included
+ here.
+
+ [Editor's note: This rule could have been omitted. However, it seems
+ preferable that any erroneous execution be as explicitly written as
+ possible - that is, the names of the components should explicitly
+ appear so that a reviewer can clearly see potential danger. That
+ seems more important with this proposal as <<>> can appear anywhere
+ in an expression, so it could be somewhat hidden if the expression
+ is large.]
+
+ Static Semantics
+
+ If <<>> appears in the expression of an assignment statement S,
+ then S is equivalent to a local object renaming that declares a
+ unique temporary name of the same type as the /variable_/name,
+ to be a renaming of the /variable_/name; this is followed by an
assignment_statement with its /variable_/name being this
- temporary name, and with its expression being a call on a
- function denoted by the underlying operator symbol, with the
- first operand being the temporary name and the second operand
- being the expression of the update_statement.
+ temporary name, and with its expression being the expression of S
+ with all of the <<>> names being replaced by the temporary name.
-Specify that the /variable_/name is a complete context,
-by adding after 8.5(8):
+ AARM Discussion:
+ For example, the expression
+ My_Array(I) := <<>>*2 + <<>>/2;
+ would be equivalent to
+ declare
+ [Target_Name] : [Target_Type] renames My_Array(I);
+ begin
+ [Target_Name] := [Target_Name]*2 + [Target_Name]/2;
+ end;
- * The /variable_/name of an update_statement.
+ All of the Dynamic Semantics follow directly from this equivalence.
+ End AARM Discussion.
-NOTE: Some change will also be needed in 2.2 Lexical Elements, ... if we
-decide to proceed further with this AI.
!examples
-X :+ 1; -- A short hand for X := X + 1;
+ X := <<>> + 1; -- A short hand for X := X + 1;
-A(I) :* 2; -- Equivalent to:
---
--- > renames A(I);
---
---
---
+ A(I) := Integer'Max (<<>>, 10); -- Equivalent to:
+ -- declare
+ -- Temp : Integer renames A(I);
+ -- begin
+ -- Temp := Integer'Max (Temp, 10);
+ -- end;
!discussion
-The update_statement is defined by equivalence to a local rename
-followed by an assignment statement with the right-hand side being a
-call on a function denoted by an operator symbol. We also specify that
-the /variable_/name is a complete context, allowing its type to be
-resolved before doing the expansion. The visibility, name resolution,
-and legality rules follow from these definitions. This is analogous to
-RM 6.6(2), which through equivalence determines all the rules of
-visibility and name resolution for operators.
-
-As indicated in the proposal, we can envision a separate AI which
-permits explicit definition of the Update_Operation to use for a
-given operator. We considered allowing explicit declarations of ":+"
-procedures, but that seemed too foreign a concept to most reviewers,
-so we would suggest this separate AI might use an Update_Operation
-aspect of an operator.
-
-We originally considered using the C-like syntax of "+=", "-=", ...,
-but the ambiguity associated with "/=" and the lack of a ":" in the
-syntax meant the proposal was not acceptable to various reviewers.
-
-We have chosen to defer proposing wording changes to "2.2 Lexical
-Elements, ..." as these seem less critical to the evaluation of this
-proposal.
+<<>> is defined by equivalence to a local rename followed by an assignment
+statement; all of the static and dynamic semantics follow from this equivalence.
+Possible issue: Resolution of an assignment_statement is unchanged when <<>>
+is used. That means that <<>> might be overloaded if the /variable_/name is
+overloaded. That might complicate the implementation a bit; care needs to be
+taken that <<>> always is resolved with the same type. (It's possible to write
+an assignment where the text is the same on both sides of the expression
+but a different function is resolved.)
+
+We considered making the /variable_/name a complete context in the case that
+<<>> is used, but that potentially would be a (minor) maintenance hazard,
+as introducing <<>> might cause a perfectly good assignment to become illegal
+(if the target is overloaded).
+
+This proposal is better than AI12-0125-2, as
+ (1) No new lexical symbols are needed.
+ (2) It is more flexible; it can be used in function calls other than operators
+ (as shown by the 'Max example above).
+ (3) It doesn't depend on visibility of anything; it's always available if the
+ assignment meets the criteria of the Legality Rules.
+
+It is different than the proposal of AI12-0125-2: (whether these are advantages
+or disadvantages are in the eye of the beholder -- the author finds these to be
+advantages)
+
+ (1) It doesn't have an "obvious" extension to a user-defined version, which
+ avoids a nasty slippery slope.
+ (2) It doesn't look like we're out of ideas by stealing groddy parts of other
+ languages.
+
!ASIS
** TBD **
@@ -128,1964 +149,5 @@
ACATS B and C-Tests would be needed.
!appendix
-
-From: Tucker Taft
-Sent: Tuesday, September 22, 2015 1:32 PM
-
-Here is an alternative version of AI12-0125, introducing the notion of an
-"Update_Statement" defined by equivalence to a longer-hand rename followed
-by an assignment. [This is AI12-0125-2/01 - Editor.]
-
-****************************************************************
-
-From: Bob Duff
-Sent: Tuesday, September 22, 2015 3:47 PM
-
-> Define +=, -=, *=, ... in terms of "+" operator, "-" operator, etc.
-
-Seems like a good idea. But shouldn't it be "+:=", etc?
-
-> The operation "/=" represents somewhat of a challenge.
-
-"/:=" ?
-
-> As indicated in the proposal, we can envision a separate AI which
-> permits explicit declaration of update operations such as "+=", but
-> that seems of lower priority.
-
-Negative priority, I'd say. ;-) Why would you want that?
-It just seems to add confusion to programs, and complexity to the language.
-
-****************************************************************
-
-From: Gary Dismukes
-Sent: Tuesday, September 22, 2015 4:03 PM
-
-> > Define +=, -=, *=, ... in terms of "+" operator, "-" operator, etc.
->
-> Seems like a good idea. But shouldn't it be "+:=", etc?
-
-That's what some preferred the last time this was discussed (Robert
-definitely felt that way, see AI05-0187). I tend to agree.
-
-...
-> Negative priority, I'd say. ;-) Why would you want that?
-> It just seems to add confusion to programs, and complexity to the
-> language.
-
-Agreed.
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Tuesday, September 22, 2015 4:04 PM
-
-> Here is an alternative version of AI12-0125, introducing the notion of
-> an "Update_Statement" defined by equivalence to a longer-hand rename
-> followed by an assignment.
-
-I would qualify this as "low cost, low benefit". But maybe good PR, and PR is
-what Ada needs...
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, September 22, 2015 4:12 PM
-
->> Define +=, -=, *=, ... in terms of "+" operator, "-" operator, etc.
->
-> Seems like a good idea. But shouldn't it be "+:=", etc?
-
-We discussed this in the ARG, but I believe the majority preferred the simpler
-syntax. It also makes things easier for users coming from other languages.
-It is a "short hand" after all... ;-)
-
->> ... As indicated in the proposal, we can envision a separate AI which
->> permits explicit declaration of update operations such as "+=", but
->> that seems of lower priority.
->
-> Negative priority, I'd say. ;-) Why would you want that?
-
-Because the update operation could be significantly more efficient when dealing
-with types like sets, matrices, etc., by avoiding the storage allocation,
-copying, etc.
-
-> It just seems to add confusion to programs, and complexity to the
-> language.
-
-Not sure why you say that. We allow people to override the default
-implementation of "=" even though the compiler will build one for you
-automatically out of a component-by-component equality.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Tuesday, September 22, 2015 6:41 PM
-
-> We discussed this in the ARG, but I believe the majority preferred the
-> simpler syntax.
-
-You mean they preferred the "less readable" syntax. ;-)
-
-Try the vote again at an ARG meeting when I'm there, and see if it comes out
-differently. Anyway, I suppose I can live with "+=".
-
->...It
-> also makes things easier for users coming from other languages. It is a
-> "short hand" after all... ;-)
-
-I don't have much sympathy for the "coming from other languages"
-argument. That's what got us "X, Y: array(...;" and then you can't say "X := Y;".
-
-> >> ... As indicated in the proposal, we can envision a separate AI
-> >> which permits explicit declaration of update operations such as
-> >> "+=", but that seems of lower priority.
-> >
-> > Negative priority, I'd say. ;-) Why would you want that?
->
-> Because the update operation could be significantly more efficient
-> when dealing with types like sets, matrices, etc., by avoiding the storage
-> allocation, copying, etc.
-
-Good point. I suppose that's why C++ allows it.
-
-But I'm not a big fan of user-defined operators on "sets, matrices, etc",
-primarily because the notations we allow don't match the maths notations.
-"<=" does NOT mean Is_Subset!
-
-So I doubt I'd use "+=" on anything but integers. (And I'm not sure I'd EVER
-use "xor=" etc. I'd be OK with just "+=" and "-=". Or better, "+:=" and
-"-:=".)
-
-> > It just seems to add confusion to programs, and complexity to the
-> > language.
->
-> Not sure why you say that. We allow people to override the default
-> implementation of "=" even though the compiler will build one for you
-> automatically out of a component-by-component equality.
-
-I think your analogy is inapt. It is sometimes useful for "=" to mean
-something other than the default. It is never useful for "+=" mean something
-other than "+" combined with ":=". (Correct me if I'm wrong!) If I'm right,
-then the ONLY reason to have user-defined "+=" is for efficiency.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, September 22, 2015 9:24 PM
-
-> Or better, "+:=" and "-:="...
-
- and /:= and *:=
-
-I will say that most of the versions including ':' look like emoticons to
-me ... ;-)
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Wednesday, September 23, 2015 3:03 AM
-
->> It just seems to add confusion to programs, and complexity to the
->> language.
->
-> Not sure why you say that. We allow people to override the default
-> implementation of "=" even though the compiler will build one for you
-> automatically out of a component-by-component equality.
-
-But here, it involves assignment. We do not allow to redefine ":=", and for
-good reasons after a language study note that lead to controlled type. How
-would such a redefinition interact with Adjust?
-
-I smell the ugly stench of a can of worms...
-
-****************************************************************
-
-From: Arnaud Charlet
-Sent: Wednesday, September 23, 2015 3:21 AM
-
-I agree with Jean-Pierre. If we allow users redefining += then we should also
-allow the redefinition of :=
-
-I also prefer += over +:= if we do introduce this new operator FWIW.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 23, 2015 7:29 AM
-
-> ... But I'm not a big fan of user-defined operators on "sets,
-> matrices, etc", primarily because the notations we allow don't match
-> the maths notations. "<=" does NOT mean Is_Subset! ...
-
-I am confused by this. Why can't you use "<=" for Is_Subset? and "<" for
-"Is_Proper_Subset"? That is what I did in the last "Set" package I built...
-
-Also, Ada already uses "+", "-", "*", etc. for Matrix/Vector operations
-(G.3.1), and "-", "and", "or", and "xor" for Set operations (A.18.9).
-
-There were some issues with "implies" for boolean, but I believe the new
-"(if A then B)" is a reasonable replacement for "implies".
-
-****************************************************************
-
-From: John Barnes
-Sent: Wednesday, September 23, 2015 7:47 AM
-
-I would leave this whole wretched topic severly alone; we have discussed it
-all before. It just makes Ada bigger and more confusing.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 23, 2015 8:24 AM
-
-I guess I don't agree. This short-hand is very straightforward, and is present
-in almost all other languages in wide use today. I do a fair amount of
-programming in other languages, and I find having to write
-"Amazing_Long_Name := Amazingly_Long_Name + 1;" one of the most tedious things
-about Ada relative to other languages. And I don't see it aiding readability
-in Ada. Rather, it merely increases the "noise" without adding anything to
-the "signal."
-
-****************************************************************
-
-From: Arnaud Charlet
-Sent: Wednesday, September 23, 2015 8:24 AM
-
-I agree with Tuck. It won't make the language more confusing IMO, it will make
-it more usable and as long as we do not enter the "redefine assignment
-operators" can of worm, the change looks pretty straightforward.
-
-I don't buy the argument "it just makes Ada bigger" since this argument would then apply to any new proposed feature.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Wednesday, September 23, 2015 8:16 AM
-
-> > ... But I'm not a big fan of user-defined operators on "sets,
-> > matrices, etc", primarily because the notations we allow don't match
-> > the maths notations. "<=" does NOT mean Is_Subset! ...
->
-> I am confused by this. Why can't you use "<=" for Is_Subset? and "<"
-> for "Is_Proper_Subset"?
-
-Because "<" in maths means "less than". It does not mean "is proper subset".
- It's bad enough that ASCII doesn't have a proper "<="
-character, but "<=" is as close as we can get to "less or equal"
--- e used to mean "is subset".
-(Unicode has subset operators, but I don't know how to type them, and Ada
-doesn't allow them as operators.)
-
->...That is what I did in the last "Set" package I built...
->
-> Also, Ada already uses "+", "-", "*", etc. for Matrix/Vector
-> operations (G.3.1),
-
-Yuck.
-
->...and "-",
-> "and", "or", and "xor" for Set operations (A.18.9).
-
-Those aren't so bad, because they make some sense mathematically (the
-intersection is those elements that are in this set AND in that set).
-
-> There were some issues with "implies" for boolean, but I believe the
-> new "(if A then B)" is a reasonable replacement for "implies".
-
-Yes, I think the if-expression is better than "implies".
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 23, 2015 8:48 AM
-
-> Because "<" in maths means "less than". It does not mean "is proper
-> subset". ...
-
-The symbol "<=" is used more generally than that within a partial ordering.
-Here is Wikipedia's entry on "partial order":
-
-A (non-strict) partial order[2] is a binary relation "<=" over a set P which
-is reflexive, antisymmetric, and transitive, i.e., which satisfies for all a,
-b, and c in P:
-
-a <= a (reflexivity);
-if a <= b and b <= a then a = b (antisymmetry); if a <= b and b <= c then
-a <= c (transitivity).
-In other words, a partial order is an antisymmetric preorder.
-
-... Standard examples of posets arising in mathematics include:
-
-...
-The set of subsets of a given set (its power set) ordered by inclusion (see the
-figure on top-right). Similarly, the set of sequences ordered by subsequence,
-and the set of strings ordered by substring. ...
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Wednesday, September 23, 2015 9:00 AM
-
-> I find having to write "Amazing_Long_Name := Amazingly_Long_Name + 1;"
-> one of the most tedious things about Ada
-
-I don't buy this one. Use GPS, type three characters and then Ctrl-/ (automatic
-completion).
-
-The only good reason is avoiding to evaluate names twice in the case of
-complicated subcomponents, possibly involving functions with side-effect.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 23, 2015 11:38 AM
-
-I think you underestimate the difficulty of encouraging programmers who are
-potential new users, to adopt Ada, presuming they are familiar with other
-languages. This sort of tedium turns them off. Yes if you are an expert these
-things become less of a burden, but for people considering the language, these
-sorts of things just make the language feel heavy and painful to use. And
-using Ctrl-/ or whatever doesn't address the fact that the resulting unhelpful
-verbosity makes the program more tedious to read as well.
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, September 24, 2015 7:58 AM
-
-We used to have the view (maybe just Jean) that programs were read many more
-times than they were written. And read by different people. So it was a good
-idea that they should all write the same way. Hence a bad idea to give too
-much choice.
-
-But I take the point about encouraging those who have been damaged by terser
-languages. Maybe we need a tool that turns a program into "standard form"
-(we would argue about that for ever I suppose). And maybe a restriction No
-Terseness.
-
-Anyway, I am going on vacation now and will see what sort of an outcome has
-emerged some time later.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 23, 2015 11:55 AM
-
->> Because the update operation could be significantly more efficient
->> when dealing with types like sets, matrices, etc., by avoiding the storage
->> allocation, copying, etc.
->
-> Good point. I suppose that's why C++ allows it. ...
-
-An alternative to the somewhat foreign idea of:
-
- procedure "+="(Left : in out T; Right : T);
-
-might be to simply define an aspect on an operator declaration that specifies
-what procedure to use when the operator appears in an update_assignment
-context. E.g.:
-
- function "*"(Left : Matrix; Right : Scalar) return Matrix
- with Update_Operation => Scale_Matrix;
-
-where Scale_Matrix is declared as:
-
- procedure Scale_Matrix(Left : in out Matrix; Right : Scalar);
-
-This would eliminate any issues of visibility or name resolution for the update
-operation at the point of use of the operator in an update_assignment, and
-instead only require visibility of Scale_Matrix at the place where the aspect
-specification is resolved.
-
-This might emphasize that this is for efficiency, not for introducing some subtly
-different meaning in the update_assignment context.
-
-****************************************************************
-
-From: Erhard Ploedereder
-Sent: Thursday, September 24, 2015 9:38 AM
-
-Can't we stick to the simple model that such operators compose but are not
-overloadable, much like /= composes from "not" and "=", but is not overloadable
-per se? (Yes, I know that the composing is not quite the case, but it makes it
-comprehensible to think about it that way.)
-
-Incidently: "/=" is an argument for me why these operators should include the
-":". I.e., "/:=", not "/=". Or else I really do not know whether "/=" stands
-for not equal or for "divide this value by ..." and PLEASE, do not rely on
-overload resolution to find out the answer!
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Thursday, September 24, 2015 11:01 AM
-
-Agreed, although I don't find "+:=" and the like very pleasant to the eye.
-Hmmm... what about ":+=", ":/=" ... (I don't mind them looking like
-smileys)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, September 24, 2015 10:07 AM
-
-> Incidently: "/=" is an argument for me why these operators should
-> include the ":". I.e., "/:=", not "/=". Or else I really do not know
-> whether "/=" stands for not equal or for "divide this value by ..."
-> and PLEASE, do not rely on overload resolution to find out the answer!
-
-It isn't overload resolution. It is the parser. There is never any ambiguity
-to resolve in the semantic phase.
-
-****************************************************************
-
-From: Erhard Ploedereder
-Sent: Thursday, September 24, 2015 11:01 AM
-
-so you are arguing that the same token "/=" stands for two entirely different
-concepts in the following two lines?
-
-x /= 7;
-
-and
-
-if x /= 7 then y /= x; else y /= 42; end if;
-
-??
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Thursday, September 24, 2015 11:09 AM
-
-> It isn't overload resolution. It is the parser. There is never any
-> ambiguity to resolve in the semantic phase.
-Yes, for a compiler; but for a human being...
-
-Assuming you have:
-function "/"(Left : integer; right : boolean) return integer;
-the following would be legal:
-
-I /= X /= 3;
-
-I think that's what Erhardt doesn't want. Certainly, that's what I don't want!
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Thursday, September 24, 2015 11:19 AM
-
-> I think you underestimate the difficulty of encouraging programmers
-> who are potential new users, to adopt Ada, presuming they are familiar
-> with other languages. This sort of tedium turns them off.
-
-Do you remember the making of Ada 2005? "It is annoying to have to declare
-all those access types, while in other languages you just stick a "*" in
-front of anything and you're done. Let's allow anonymous access types
-everywhere"
-
-Which lead to a terrible mess that we regret now...
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, September 24, 2015 11:52 AM
-
-I agree with JP. Indeed anonymous access types were a terrible disaster. I
-down played them when rewriting my book. I wish I had removed all mention of
-them.
-
-Please be careful not to screw this language up any more.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, September 24, 2015 11:49 AM
-
-Interestingly, it was one John Barnes who wrote the AI on allowing
-stand-alone objects of an anonymous access type. I believe this was
-one of the rare AIs that I did not favor. ;-)
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, September 24, 2015 1:52 PM
-
-It was such a mess that John Barnes thought it would straightent it out.
-The mess came much earlier! Water under the bridge. The bridge of sighs
-perchance.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, September 24, 2015 11:52 AM
-
-> Agreed, although I don't find "+:=" and the like very pleasant to the
-> eye. Hmmm... what about ":+=", ":/=" ... (I don't mind them looking
-> like
-> smileys)
-
-Another alternative would be to eliminate the '=' completely:
-
- X :+ 5;
- X :/ 2;
-
-****************************************************************
-
-From: Edmond Schonberg
-Sent: Thursday, September 24, 2015 12:22 PM
-
-...
-> I /= X /= 3;
->
-> I think that's what Erhardt doesn't want. Certainly, that's what I
-> don't want!
-
-Strongly agree. The colon should remain to indicate that this is an assignment.
-It’s not the parsing issue, which remains trivial, it’s the looks of it.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Thursday, September 24, 2015 2:11 PM
-
-> The symbol "<=" is used more generally than that within a partial
-> ordering. Here is Wikipedia's entry on "partial order":
->
-> A (non-strict) partial order[2] is a binary relation "<=" over a set P
-> which is reflexive, antisymmetric, and transitive, i.e., which satisfies for
-> all a, b, and c in P:
->
-> a <= a (reflexivity);
-> if a <= b and b <= a then a = b (antisymmetry); if a <= b and b <= c
-> then a <= c (transitivity).
-> In other words, a partial order is an antisymmetric preorder.
->
-> ... Standard examples of posets arising in mathematics include:
->
-> ...
-> The set of subsets of a given set (its power set) ordered by inclusion
-> (see the figure on top-right). Similarly, the set of sequences ordered
-> by subsequence, and the set of strings ordered by substring. ...
-
-I think that's when one is studying partial orders. A maths paper about
-partial orders might use "<=" as a generic[*] operator that stands for any
-operator with the relevant properties (which could indeed be "is subset").
-But a maths paper about sets will use the rounded "subset" operator that I
-don't know how to type, not "<=" (which I also don't know how to type).
-And until Ada allows overloading of unicode operators, I think the set
-function should be called Is_Subset.
-
-[*] I don't mean generic in the Ada sense.
-
-But anyway, I suggest we all stop talking about user-defined "+=", because
-otherwise we'll convince people like John that the whole thing is a
-complicated mess. Let's focus on the important point, which is that:
-
- My_Array(X).Comp.Blah := My_Array(X).Comp.Blah + 1;
-
-is unreadable because one must carefully compare the two names to see if they
-are identical.
-
-We need to decide whether it's += or +:= or :+ or :+= or something else.
-I suppose I could live with any of those, but I agree with those who don't like
-the conflict with "/="; therefore "+=" is my least favorite.
-
-I suggest we discuss user-defined "+=" only after ARG passes the language-defined
-"+=" idea. I'll argue against the user-defined one at that time.
-
-****************************************************************
-
-From: Erhard Ploedereder
-Sent: Thursday, September 24, 2015 6:07 PM
-
-> I suggest we discuss user-defined "+=" only after ARG passes the
-> language-defined "+=" idea. I'll argue against the user-defined one
-> at that time.
-
-.. and I'll join you enthusiastically.
-
-****************************************************************
-
-From: John Barnes
-Sent: Friday, September 25, 2015 1:10 AM
-
-If we just need a shrthand for a long LHS why not a symbol meaning just that
-
-How about
-
-replacing
-
-longname := longname + 1;
-
-by
-
-longname := [] + 1;
-
-So [] just mean the aforementioned LHS.
-
-No new operations requiared.
-
-Must dash for a plane.
-
-****************************************************************
-
-From: Jeff Cousins
-Sent: Friday, September 25, 2015 7:31 AM
-
-> longname := [] + 1;
-
-> So [] just mean the aforementioned LHS.
-
-I was about to propose something similar, but being persona non grata on the
-ARG list I can’t simply hit Reply.
-
-It has always irritated me about the C family of languages that it’s
-
-longname += 1;
-
-whereas to keep the same order of operators as in
-
-longname = longname + 1;
-
-it should be
-
-longname =+ 1;
-
-
-So that led me to
-
-longname :=+ 1;
-
-Then I thought, why not allow optional whitespace between the := and the +,
-so that either nothing or whitespace between the := and the + meant assume
-the LHS.
-
-But then I thought that the programmer could have accidentally cut a variable
-between the := and the +, so to guard against that something short and snappy
-should go between the := and the +, say
-
-longname := <> + 1;
-
-****************************************************************
-
-From: Bob Duff
-Sent: Friday, September 25, 2015 8:03 AM
-
-I suggested something like that a long time ago. I don't particularly like
-the "[]" notation, but I don't remember what I suggested.
-People didn't like the idea, as I recall.
-
-It has the advantage of generality:
-
- x := f([]);
- y := g([], 123);
-
-****************************************************************
-
-From: Brad Moore
-Sent: Friday, September 25, 2015 8:31 AM
-
-Perhaps it would help if the symbol used is "<<" as it "points" to the lhs
-variable that is being substituted.
-
-eg.
-
-longname := << + 1;
-
-x := f(<<);
-y := g(<<, 123);
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Friday, September 25, 2015 8:49 AM
-
-...
-> So [] just mean the aforementioned LHS.
-
-It would seem odd to use the '[' and ']' characters only for this one feature.
-Jeff suggested using "<>" which seems a ready-made symbol that tends to mean
-"fill in the blank with the obvious thing" which seems just about right.
-
-As Bob pointed out, this would generalize nicely for things like "Max":
-
- Max_Of_Arr := Integer'Max(<>, A(I));
-
-Using "<<" for this as Brad suggested seems to be almost thumbing our nose at
-the many languages that use this symbol to mean "left shift."
-
-****************************************************************
-
-From: Edmond Schonberg
-Sent: Friday, September 25, 2015 8:50 AM
-
-Much prefer <> which is an existing token that denotes elsewhere some obvious
-default for a value.
-
-****************************************************************
-
-From: Tullio Vardanega
-Sent: Friday, September 25, 2015 8:56 AM
-
-I like Jeff's proposal, and the reasoning behind it.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Friday, September 25, 2015 9:21 AM
-
-I can re-do the AI to use "<>" if that would be useful.
-
-****************************************************************
-
-From: Steve Baird
-Sent: Friday, September 25, 2015 11:34 AM
-
-Don't forget to handle the case where the RHS contains an
-already-legal-by-today's-rules use of <>.
-
-Presumably we don't want
- X := F (T'(A => 123, B => <>));
-to become ambiguous or change meaning.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Friday, September 25, 2015 11:47 AM
-
-Good point!
-
-****************************************************************
-
-From: Gary Dismukes
-Sent: Friday, September 25, 2015 12:47 PM
-
-This is starting to seem like deja vu all over again...
-
-I made a proposal for this approach back in 2009 that became AI05-0187.
-
-That resulted in a very lengthy discussion of this as well as the "op="
-and the 'Inc/'Dec alternatives. It's funny how much discussion can be
-generated for "simple" features (as Robert was fond of pointing out).
-
-There wasn't a clear consensus resulting from that discussion, and the
-result was dropping it for Ada 2012, but I guess that led to being later
-resurrected as AI12-0125-1 (and 0125-2). It may be instructive (as well as
-entertaining) for people to review the 0187 discussion, if you have that sort
-of time on your hands. :-) FWIW, at the time there seemed to be somewhat
-more support for the "op=" (or "op:=") than the more general token-based form.
-
-And Tuck wrote:
-
-> It would seem odd to use the '[' and ']' characters only for this one
-> feature. Jeff suggested using "<>" which seems a ready-made symbol
-> that tends to mean "fill in the blank with the obvious thing" which seems
-> just about right.
->
-> As Bob pointed out, this would generalize nicely for things like "Max":
->
-> Max_Of_Arr := Integer'Max(<>, A(I));
->
-> Using "<<" for this as Brad suggested seems to be almost thumbing our
-> nose at the many languages that use this symbol to mean "left shift."
-
-My strawman suggestion in AI05-0187 was to use <<>> rather than <>, one reason
-being the conflict with <> in aggregates (as Steve pointed out today). If we
-were to go this direction, I think it helps to have a token that reasonably
-obtrusive.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Friday, September 25, 2015 1:08 PM
-
-...
-> > Presumably we don't want
-> > X := F (T'(A => 123, B => <>));
-> > to become ambiguous or change meaning.
->
-> Good point!
-
-Yes. It makes me like Brad's suggestion of << , or Gary's suggestion of <<>>.
-
-****************************************************************
-
-From: Arnaud Charlet
-Sent: Saturday, September 26, 2015 4:06 AM
-
-> If we just need a shrthand for a long LHS why not a symbol meaning
-> just that How about replacing
->
-> longname := longname + 1;
->
-> by
->
-> longname := [] + 1;
->
-> So [] just mean the aforementioned LHS.
->
-> No new operations requiared.
-
-Well, I'm afraid the above generalization will:
-- introduce much more complexity for everyone (implementers, writers,
- readers, reviewers, QA people, ...), for a feature that nobody has asked for
-- it's much less readable IMO to have:
-
- Long_LHS := Long_Expression + <<>> + Another_Long_Expr ...;
-
- where it's actually very easy to miss what's going on, as opposed to
- the much simpler and clear to all:
-
- Long_LHS += Long_Expression + Another_Long_Expr;
-
-If we really allow this new <> or <<>> symbol, we are really letting best be
-the ennemy of good IMO :-(
-
-I'd rather not change anything in the language than introduce this new much
-more complex concept.
-
-For instance having:
-
- Some_LHS := Complex_Expression (Something).Component (<>) +
- Another_Complex_Expr * ...
-
-makes it very easy to miss the implicit reference to the LHS, and <> in this
-context doesn't mean at all "replace by the obvious thing", since there is
-*no* obvious replacement in such complex context.
-
-Since we're talking about a shorthand and making it easy for people to read and
-write, the similarly with other languages *is* important at this stage since:
-- it makes adoption of the language and training easier
-- it makes reading from non Ada experts easier. Think about code reviewers,
- QA people, certification experts who may not be Ada experts, but simply
- know enough about many languages. Do you really think these people will
- find the <> or <<>> notation obvious compared to the += notation? I
- certainly don't and know that the opposite will be true.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Wednesday, September 30, 2015 4:50 PM
-
-...
-> This is starting to seem like deja vu all over again...
-
-Starting?? :-)
-
-> I made a proposal for this approach back in 2009 that became
-> AI05-0187.
-
-Yes. Thanks for telling everyone that we've already done this.
-
-> That resulted in a very lengthy discussion of this as well as the "op="
-> and the 'Inc/'Dec alternatives. It's funny how much discussion can be
-> generated for "simple" features (as Robert was fond of pointing out).
-
-Yes. Lots of issues were pointed out that never came up here. In particular,
-Dan Eilers (I think) pointed out a serious resolution issue with the "op="
-alternative. I don't know if Tucker addressed that, but it better be
-addressed or that alternative is a non-starter.
-
-> There wasn't a clear consensus resulting from that discussion, and the
-> result was dropping it for Ada 2012, but I guess that led to being
-> later resurrected as AI12-0125-1 (and 0125-2). It may be instructive
-> (as well as
-> entertaining) for people to review the 0187 discussion, if you have
-> that sort of time on your hands. :-) FWIW, at the time there seemed
-> to be somewhat more support for the "op="
-> (or "op:=") than the more general token-based form.
-
-The reason that I proposed the 'Inc/'Dec (or 'Succ/'Pred) alternative this
-time is that it is clear to me that a more general mechanism will not get
-enough traction to pass. The attribute does not require new syntax (or
-lexing!), and it cleanly solves the common problem of <long> := <long> + 1;
-without trying to be all things to all people. And it *looks* like Ada
-(indeed, as I've previously pointed out, this is what I thought 'Succ and
-'Pred were for initially; they're rather useless outside of generics in
-their current form, and Modula had built-in Inc and Dec procedures for this
-purpose.)
-
-> And Tuck wrote:
->
-> > It would seem odd to use the '[' and ']' characters only for this one
-> > feature. Jeff suggested using "<>" which seems a ready-made symbol
-> > that tends to mean "fill in the blank with the obvious thing" which
-> > seems just about right.
-> >
-> > As Bob pointed out, this would generalize nicely for things like "Max":
-> >
-> > Max_Of_Arr := Integer'Max(<>, A(I));
-> >
-> > Using "<<" for this as Brad suggested seems to be almost thumbing our
-> > nose at the many languages that use this symbol to mean "left shift."
->
-> My strawman suggestion in AI05-0187 was to use <<>> rather than <>,
-> one reason being the conflict with <> in aggregates (as Steve pointed
-> out today). If we were to go this direction, I think it helps to have
-> a token that reasonably obtrusive.
-
-Agreed.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Wednesday, September 30, 2015 4:58 PM
-
-> > Seems like a good idea. But shouldn't it be "+:=", etc?
->
-> That's what some preferred the last time this was discussed (Robert
-> definitely felt that way, see AI05-0187). I tend to agree.
-
-It has to be "+:=" or something like that. "=" is equality, not assignment,
-and I don't think there is much need for a combined plus and equality ;-).
-
-I came to Ada in the first place because it comes closest of any practical
-language to getting the syntax right. I will not allow the syntax (and meaning)
-to be destroyed by adding operators that don't make any sense in existing Ada.
-Meaning I would fight "+=" (as opposed to "+:=") at every level -- you'd have
-to fire me as editor to put that into the language -- I will NOT do that.
-
-[I probably would have made that point in Madrid if I wasn't nearly passed out
-during the Sunday morning discussions. Still not quite sure what happened
-there.]
-
-P.S. I feel the about the same way about shifting "operators", BTW. Probably
-not quite to the point of quitting, but very, very negative.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Friday, September 30, 2015 5:25 PM
-
-> Well, I'm afraid the above generalization will:
-> - introduce much more complexity for everyone (implementers, writers,
-> readers, reviewers, QA people, ...), for a feature that nobody has
-> asked for
-
-Huh? The problem of long-LHSes has been one that people have been asking for
-a solution to for decades. And this particular solution was suggested the last
-time we considered the long-LHS problem. Perhaps no AdaCore customers have
-asked for this feature, but surely it has been asked for (long ago) on
-comp.lang.ada and most likely other forums.
-
-...
-> I'd rather not change anything in the language than introduce this new
-> much more complex concept.
-
-Again, this is why I suggested adding 'Succ and 'Pred procedures (or 'Inc/'Dec
-if you prefer) and leaving all of these wars alone.
-
-My ranking of the proposals:
-
- 1) <<>> (but argubly too complex)
- 2) 'Inc/'Dec attributes
- ...
- 32768) +:= operators
- ...
- googleplex) += operators
-
-> For instance having:
->
-> Some_LHS := Complex_Expression (Something).Component (<>)
-> + Another_Complex_Expr * ...
->
-> makes it very easy to miss the implicit reference to the LHS, and <>
-> in this context doesn't mean at all "replace by the obvious thing",
-> since there is *no* obvious replacement in such complex context.
-
-<> is not a serious syntax suggestion, it has too many conflicts.
-
- Some_LHS := Complex_Expression (Something).Component (<<>>) +
- Another_Complex_Expr * ...
-
-is the serious proposal. (Or [], but that brings back in the need for new
-lexical tokens.)
-
-On top of which, I think that semantically this would be a rename. That is,
-if <<>> appears in the expression, then the expression really is:
-
- declare
- <anon> : <LHS_Type> renames Some_LHS;
- begin
- <anon> := ... <anon> ...;
- end;
-
-This implies that the legality rules for renames are enforced on the LHS in
-such a case (as well as not allowing <<>> in expressions that aren't the RHS
-of an assignment). I think that would eliminate most if not all of the
-anomolies that could otherwise occur, and would give a clear meaning in all
-cases.
-
-(Aside: I wonder if that isn't necessary for +:= as well; else it would be
-possible to assign into a non-existent component.)
-
-> Since we're talking about a shorthand and making it easy for people to
-> read and write, the similarly with other languages
-> *is* important at this stage
-
-If that's *really* true, then the Ada I care about is already dead. (And we
-should make no change here.) I came to Ada because it has the most perfect
-syntax of the widely available languages; it does not have a garbage syntax
-of most other languages. I do not want to adopt garbage syntax ideas from other
-languages (especially from the C family of crappy syntaxes).
-
-After all, virtually every idea we've adopted from the C family has been
-misguided or worse (think anonymous access types). The fact that everyone else
-is doing stupid things is not a very good reason for us to start doing the
-same stupid things.
-
-If we really wanted to be more like other languages, we should allow replacing
-<something> End pairs with {}. (That's a joke, not a serious suggestion!!!)
-
-> since:
-> - it makes adoption of the language and training easier
-> - it makes reading from non Ada experts easier. Think about code reviewers,
-> QA people, certification experts who may not be Ada experts, but simply
-> know enough about many languages. Do you really think these people will
-> find the <> or <<>> notation obvious compared to the += notation? I
-> certainly don't and know that the opposite will be true.
-
-This is a strawman, since there is no realistic chance that either <<>> or
-+= will be adopted (I don't think the membership of the ARG has changed
-enough since AI05-0187 for a consensus to be reached).
-
-The only realistic idea was the attributes that Tucker originally proposed
-during the discussion of AI05-0187 and never were given a fair hearing at that
-time. They don't require any new syntax or (worse) lexical changes, they fit in
-cleanly to the existing Ada model, and they don't get into anything that ought
-to be controversial. I realize that they're a second choice for many, but even
-if a future consensus does develop on some more advanced feature, they will not
-look out of place. That's surely not true for "+="!!
-
-Anyway, I proposed those attributes because they were the only realistic change
-that might get made to ease the long LHS problem. I definitely did NOT intend
-for that proposal to be a reason to rehash all of the tired arguments about more
-complex features that we will never adopt.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Wednesday, September 30, 2015 5:38 PM
-
-> > I like Jeff's proposal, and the reasoning behind it. ...
->
-> I can re-do the AI to use "<>" if that would be useful.
-
-I for one would like to see it, but as a separate alternative. We can then get a
-3-3-3-1 vote on which alternative they prefer. ;-)
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Wednesday, September 30, 2015 5:50 PM
-
-> Then I thought, why not allow optional whitespace between the := and the +,
-> so that either nothing or whitespace between the := and the + meant assume
-> the LHS.
-
-> But then I thought that the programmer could have accidentally cut a variable
-> between the := and the +, so to guard against that something short and snappy
-> should go between the := and the +, say
-
-> longname := <> + 1;
-
-So we've gone from a "shorthand" to a "longhand"?? :-)
-
-Your analysis is correct, of course. But I wouldn't go so far as to allow
-whitespace, as that's the thing that triggers the cut-and-paste issues. It also
-would be ambiguous:
-
- longname := +1;
-could be
- longname := (+1);
-or
- longname :=+ (1);
-
-Since "longname := +1" is currently legal Ada, you'd be introducing a
-compatibility problem where none of the other proposals have one. That seems
-like a non-starter to me.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, September 30, 2015 9:51 PM
-
-> ... In particular,
-> Dan Eilers (I think) pointed out a serious resolution issue with the "op="
-> alternative. I don't know if Tucker addressed that, but it better be
-> addressed or that alternative is a non-starter.
-
-Looking back at this Ada 2005 AI, it appears only you and Dan considered this
-a serious resolution issue. I don't want to re-hash Dan's particular concern,
-but I believe the AI I wrote implied that the type of the LHS must be
-unambiguously resolvable (and clearly the AI should be more explicit about it),
-since it started off with an object renaming where "Type-of-LHS" was part of
-the expansion.
-
-For what it is worth, the straw poll seemed to favor the use of some variant
-of op= over <<>> or 'inc/'dec.
-
-By our recent discussions I have been convinced, by the annoying "/="
-situation, that "op=" won't fly.
-
-I think I will send in an updated AI proposing the syntax ":+", ":-", ":*",
-":/" ... just to have something new to talk about in Vermont... ;-) These
-appeal to me because they are very "different" looking symbols from any
-existing Ada ones, and they sort of make sense because ":=" is making the LHS
-and the RHS equal, while the others are updating the LHS as indicated.
-
-Feel free to flame now, or hold your flames until the revised AI shows up...
-
-****************************************************************
-
-From: Randy Brukardy
-Sent: Thursday, October 1, 2015 12:00 AM
-
-> > ... In particular,
-> > Dan Eilers (I think) pointed out a serious resolution issue with the "op="
-> > alternative. I don't know if Tucker addressed that, but it better be
-> > addressed or that alternative is a non-starter.
->
-> Looking back at this Ada 2005 AI, it appears only you and Dan
-> considered this a serious resolution issue. I don't want to re-hash
-> Dan's particular concern, but I believe the AI I wrote implied that
-> the type of the LHS must be unambiguously resolvable (and clearly the
-> AI should be more explicit about it), since it started off with an
-> object renaming where "Type-of-LHS" was part of the expansion.
-
-Since that's not the way Ada resolution typically works, and it's different
-than the way resolution works for ":=", it had better be clear in the AI how
-it works. It's probably not a big deal, but it does mean that not all
-expressions <Something> := <Something> + 1; can be written as <Something>
-+:= 1; -- most likely the AI ought to mention that as well. (The same is
-true for <<>> or even 'Inc, so it's not an advantage or disadvantage between
-those, it just needs to be called out since it is not obvious.)
-
-> For what it is worth, the straw poll seemed to favor the use of some
-> variant of op= over <<>> or 'inc/'dec.
-
-I think we'll have straw poll problems with this AI, as I wouldn't expect
-anyone to think 'inc/'dec is their first choice (it not mine). But if they
-can't have their first choice, I think many will prefer 'inc/'dec to an
-overly complicated (or obnoxous) alternative. Thus the typical way we conduct
-straw polls won't work (we'd throw out the simple compromise solution first,
-then leaving us with two alternatives that most likely cannot get consensus;
-that's precisely what happened with AI05-0187).
-
-I remain convinced that neither "+:=" nor "<<>>" could get consensus, and thus
-'Inc/'Dec is the only option that has a realistic chance of ever appearing
-in the language.
-
-> By our recent discussions I have been convinced, by the annoying "/="
-> situation, that "op=" won't fly.
->
-> I think I will send in an updated AI proposing the syntax ":+", ":-",
-> ":*", ":/" ... just to have something new to talk about in Vermont...
-> ;-) These appeal to me because they are very "different" looking
-> symbols from any existing Ada ones, and they sort of make sense
-> because ":=" is making the LHS and the RHS equal, while the others are
-> updating the LHS as indicated.
->
-> Feel free to flame now, or hold your flames until the revised AI shows
-> up...
-
-I don't want to rehash what already has been said on this topic, I doubt it
-would change anyone's mind. But updating the AI to properly deal with the
-resolution and legality rules would seem to be valuable (if only to show how
-complex this "simple" solution is :-).
-
-BTW, if you are using a renames equivalence, then you have to enforce at least
-8.5.1(5/3) [it doesn't make sense to allow implicitly renaming something that
-you can't explicitly rename] {I don't think the other legality rules are
-relevant}.
-
-I thought that might be a problem for <<>> (which would certainly has to be a
-renames equivalence), and surely the same applies to +:= (or whatever) if
-you're using a similar equivalence.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, October 1, 2015 11:54 AM
-
-Here is a revision, using ":+", ":-", ... instead of "+=", "-=", ...
-It also incorporates the specification that the LHS of an update_statement is
-a complete context, so it is possible to fill in the type in the expansion of
-the update_statement into an object_renaming followed by an assignment,
-without any fancy overload resolution. [This is version /02 of the AI -
-Editor.]
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 12:31 PM
-
-> An update_statement is equivalent to a
-> local object renaming that declares a unique temporary name
-> of the same type as the /variable_/name, to be a renaming of
-> the /variable_/name;
-
-A very minor point crossed my mind; I'm not claiming this is a big deal, just
-a detail that needs to be dealt with correctly.
-
-We might need a To Be Honest note stating that this equivalence isn't
-guaranteed to be quite right with respect to the ordering of some events.
-
-Consider
-
- My_Array (Func_1.Integer_Field) :+ Func_2.Integer_Field;
-
-vs
-
- declare
- Ren : Element_Type renames
- My_Array (Func_1.Integer_Field);
- begin
- Ren := Ren + Func_2.Integer_Field;
- end;
-
-Suppose further that the result types of the two functions require
-finalization.
-
-Consider the allowed orderings of the following 4 events
- the call to Func_1
- the finalization of the result of calling Func_1
- the call to Func_2
- the finalization of the result of calling Func_2 for each of the two
- formulations.
-
-In the first case, absent any special rules to the contrary, I'd say that the
-allowed orderings are
-
- call the two functions in either order; then
- finalize the two function results in either order
-
-In the second case, there is only one allowed ordering
-
- call func_1
- finalize func_1 result
- call func_2
- finalize func__2 result
-
-Note that the one-and-only allowed ordering for the second case is not one of
-the allowed orderings for the first case.
-
-We'd probably want to include an implementation permission allowing the
-ordering of the second formulation in the case of the first formulation because
-we want to allow (but not, of course, require) implementations to implement
-this via a source-to-source transformation.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, October 1, 2015 12:50 PM
-
-Do we need to allow any flexibility here? Why not simply expect that the
-evaluations happen in the ordering determined by the stated equivalence:
-
- call func1, finalize func1, call func2, finalize func2.
-
-There seems no implementation hardship in following this order.
-
-With user-defined iterators, we have a precedent in Ada 2012 for a relatively
-complex expansion from the original syntax to the expanded semantics. As of
-yet I don't see a need in these kinds of "syntactic sugaring"s to allow too
-much flexibility.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Thursday, October 1, 2015 12:53 PM
-
-> Note that the one-and-only allowed ordering for the second case is not
-> one of the allowed orderings for the first case.
-
-What are the first and second cases to which you refer?
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 12:58 PM
-
-> Consider
->
-> My_Array (Func_1.Integer_Field) :+ Func_2.Integer_Field;
->
-> vs
->
-> declare
-> Ren : Element_Type renames
-> My_Array (Func_1.Integer_Field);
-> begin
-> Ren := Ren + Func_2.Integer_Field;
-> end;
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 1:05 PM
-
-> Do we need to allow any flexibility here? Why not simply expect that
-> the evaluations happen in the ordering determined by the stated
-> equivalence:
->
-> call func1, finalize func1, call func2, finalize func2.
->
-> There seems no implementation hardship in following this order.
-
-I agree, that would work.
-
-I think that when defining an equivalence that introduces a new master, it is
-important to state that this equivalence overrides the usual 7.6.1 rules.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, October 1, 2015 2:03 P
-
-> > Note that the one-and-only allowed ordering for the second case is
-> > not one of the allowed orderings for the first case.
->
-> What are the first and second cases to which you refer?
-
-Steve is confused. There is no "first" case, because :+ means exactly the
-renames expansion, nothing more and nothing less. He was fantisizing about
-a :+ which was a true operation of some sort, but Tucker is not proposing
-that (for various good reasons, including the fact that some updates would
-not be resolvable).
-
-> With user-defined iterators, we have a precedent in Ada 2012 for a relatively
-> complex expansion from the original syntax to the expanded semantics. As of
-> yet I don't see a need in these kinds of "syntactic sugaring"s to
-> allow too much flexibility.
-
-'Old is also an example of a complex expansion.
-
-But in both of those cases, the Legality Rules are explicitly given for the
-new construct (we don't assume that they pass through). One has to do that
-here, too. In particular, if the renames would be illegal, the update construct
-should not be allowed.
-
-A specific example of that:
-
- type Mutable (D : Boolean := True) is record
- case D is
- when True =>
- I : Integer;
- when False =>
- F : Float;
- end case;
- end record;
-
- Obj : Mutable;
-
- ...
-
- Obj.I :+ 1; -- Has to be illegal.
-
-as the expansion:
-
- declare
- <anon> : Integer renames Obj.I;
- begin
- <anon> := <anon> + 1;
- end;
-
-is illegal (the renames is illegal as it is renaming a discriminant-dependent
-component).
-
-The case where this matters is somewhat pathological, but it exists:
-
- function Fooey return Integer is
- Temp : Integer := Obj.I;
- begin
- Obj := (D => False, F => Float(Temp));
- return Temp;
- end Fooey;
-
- Obj.I :+ Fooey; -- !!
-
-In this case, the updated component no longer exists when it is written.
-That can't be good.
-
-Anyway, my point is that we need at least a statement that the update operation
-is illegal if the expanded renames would be illegal (there is a similar
-statement in 5.5.2(6.2/4)), or you could simply copy 8.5.1(5/3) to apply to
-update operations (none of the other legality rules would apply, I think, as
-we know the type is the right one). Either would be fine, neither is not.
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 2:52 PM
-
-...
-> as the expansion:
->
-> declare
-> <anon> : Integer renames Obj.I;
-> begin
-> <anon> := <anon> + 1;
-> end;
->
-> is illegal (the renames is illegal as it is renaming a
-> discriminant-dependent component).
-
-If we wanted to allow this case, we could define the expansion not in terms
-of a rename but rather in terms of a call to an implicitly declared "update"
-subprogram.
-
-That is,
-
- A :+ B;
-
-is equivalent to
-
- declare
- procedure Update (Target : in out T; Addend : T) is
- begin
- Target := Target + Addend;
- end;
- begin
- Update (Target => A, Addend => B);
- end;
-
-This would allow the common cases, but the Fooey pathogy would become
-erroneous instead of illegal (by 3.7.2(4)).
-
-The parameter subtypes would have to be unconstrained, predicateless, and
-whatever else it takes to ensure that parameter passing doesn't introduce
-any unwanted checks.
-
-The subprogram would be anonymous, not named Update.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, October 1, 2015 3:10 PM
-
-I find this an attractive alternative. Renaming is a bit of a kludge, and as
-we see has its own issues with components of discriminated records. I would
-think the first parameter subtype would be exactly the nominal subtype of the
-LHS, no more, no less, and the second parameter subtype would similarly come
-from the nominal subtype of the RHS. I am sure Steve will enlighten me if
-these don't work ...
-
-For what it is worth, it also naturally explains how an Update_Operation aspect
-on an operator could work.
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 3:42 PM
-
-> I would think the first parameter subtype would be exactly the nominal
-> subtype of the LHS, no more, no less, and the second parameter subtype
-> would similarly come from the nominal subtype of the RHS. I am sure
-> Steve will enlighten me if these don't work ...
-
-It doesn't make much difference, but why wouldn't you want to use the same
-parameter subtype that is already used for other predefined operators (e.g.,
-"+")?
-
-With the Update procedure formulation, we get an extra subtype conversion at
-the start of the call.
-
-It's like we are transforming
- X := X + Y;
-into
- X := S1'(S1'(X) + S2'(Y));
-and we want to choose S1 and S2 to minimize the impact of this.
-
-The unconstrained basetype seems like the obvious choice, but I think the
-nominal subtypes would also work.
-
-The only thing that comes to mind is badly behaved predicates, but I can
-already anticipate the response of "so don't do that".
-
-As long as we are only working with scalars, we don't have to worry about
-anonymous types. I also don't see any problems if the nominal subtype is
-anonymous, as in
-
- type Vec is array (Boolean) of Integer range 1 .. N;
- X : Vec := ... ;
- begin
- X (True) :+ 1;
-
-but, again, the basetype seems slightly simpler.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Thursday, October 1, 2015 3:46 PM
-
-> Obj.I :+ Fooey; -- !!
-
-Why do you say that HAS to be illegal? It could be erroneous.
-
-I believe this:
-
- Obj.I := Obj.I + Fooey; -- !!
-
-is erroneous. I hate erroneousness, but it's not like this is a new case, and
-it's pretty obscure.
-
-Why don't we define the semantics the way a normal user would think about it,
-instead of dragging in renamings and nested anonymous procedures and all the
-usual RM-ese?
-
- An update_statement of the form "name :+ expression;" is equivalent
- to the assignment_statement "name := name + expression;",
- except that the name is evaluated only once. Other update
- operators have corresponding semantics.
-
-With "name" and "expression" in italics.
-I know it sounds kind of informal, but could it be misunderstood?
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, October 1, 2015 4:09 PM
-
-> > Obj.I :+ Fooey; -- !!
->
-> Why do you say that HAS to be illegal? It could be erroneous.
-
-It has to be illegal given the renames formulation, as the renames is
-illegal. I didn't think about any other formulation.
-
-> I believe this:
->
-> Obj.I := Obj.I + Fooey; -- !!
->
-> is erroneous. I hate erroneousness, but it's not like this is a new
-> case, and it's pretty obscure.
->
-> Why don't we define the semantics the way a normal user would think
-> about it, instead of dragging in renamings and nested anonymous
-> procedures and all the usual RM-ese?
->
-> An update_statement of the form "name :+ expression;" is equivalent
-> to the assignment_statement "name := name + expression;",
-> except that the name is evaluated only once. Other update
-> operators have corresponding semantics.
->
-> With "name" and "expression" in italics.
-> I know it sounds kind of informal, but could it be misunderstood?
-
-This the ARG, so we can find dozens of ways. ;-)
-
-Seriously, given that the expressions potentially include controlled parts,
-anonymous types (and allocators!), and other such nonsense, I think a
-concrete definition is best. Otherwise, we'll be making an ARG full employment
-act answering questions about all of the weird cases raised. We went through
-that with 'Old, where the informal definition just wasn't specific enough. I'd
-expect the same here (the level is similar).
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, October 1, 2015 4:03 PM
-
-> > The parameter subtypes would have to be unconstrained,
-> > predicateless, and whatever else it takes to ensure that parameter
-> > passing doesn't introduce any unwanted checks.
-> >
-> > The subprogram would be anonymous, not named Update.
->
-> I find this an attractive alternative. Renaming is a bit of a kludge,
-> and as we see has its own issues with components of discriminated
-> records. I would think the first parameter subtype would be exactly
-> the nominal subtype of the LHS, no more, no less, and the second
-> parameter subtype would similarly come from the nominal subtype of the
-> RHS. I am sure Steve will enlighten me if these don't work ...
-
-That would at least canonically add some checks because of the parameter
-passing (for instance, if the nominal subtype had a predicate). That could
-cause Constraint_Error to be raised in cases where it wouldn't be for the
-"long-hand" form. Not sure if that's a problem (most such cases - at least
-the ones I can think of - involve invalid values).
-
-In addition, I don't think that the nominal subtype of the RHS is right.
-It's the nominal subtype of the "Right" parameter of the operator, not the
-RHS expression, that would need to be used. The difference is apparent in
-something like:
-
- type First_is_10 is array (Positive range <>) of Character
- with Dynamic_Predicate => Exactly_4'First = 10;
-
- Obj : First_is_10 := (10 => 'A');
-
- Obj :& "AA"; -- (1)
-
-[Yes, I realize this will always raise Constraint_Error because we can't change
-the length of Obj. There's probably a better example but I don't want to waste
-time finding it right now.]
-
-Anyway, the nominal subtype of "AA" is going to be "First_is_10", and the lower
-bound of "AA" is going to be 1, so the predicate would fail. OTOH, the nominal
-subtype of the "&" operator is the italized T (which has no bounds or
-predicates), and that's what we'd want the subtype of the virtual subprogram
-to be.
-
-BTW, in the case of <<>>, I think it is better for it to be illegal than to be
-erroneous, as <<>> can be used anywhere and thus the pathology is more likely
-(maybe it isn't a pathology in that case?). Perhaps one could make an exception
-for the case when no functions appear in the expression (there would be no
-problem in that case) [clearly the same would work for :+].
-
-> For what it is worth, it also naturally explains how an
-> Update_Operation aspect on an operator could work.
-
-Ugh. Let me try not to gag. (BTW, I'd put that part in the !discussion of the
-AI, rather than the !proposal, as it's not really part of the proposal and has
-the potential to cause people to vote against the proposal specifically because
-of that idea.)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, October 1, 2015 4:05 PM
-
->> I would think the first parameter subtype would be exactly the
->> nominal subtype of the LHS, no more, no less, and the second
->> parameter subtype would similarly come from the nominal subtype of
->> the RHS. I am sure Steve will enlighten me if these don't work ...
->
-> It doesn't make much difference, but why wouldn't you want to use the
-> same parameter subtype that is already used for other predefined
-> operators (e.g., "+")?
-
-Perhaps because the operator you are calling might not be predefined.
-
-> With the Update procedure formulation, we get an extra subtype
-> conversion at the start of the call.
->
-> It's like we are transforming
-> X := X + Y;
-> into
-> X := S1'(S1'(X) + S2'(Y));
-> and we want to choose S1 and S2 to minimize the impact of this.
->
-> The unconstrained basetype seems like the obvious choice, but I think
-> the nominal subtypes would also work. ...
-
-The notion of "basetype" is only defined for scalar types. The notion of an
-"unconstrained" type can be tricky in the presence of type extensions where
-the parent subtype is constrained.
-
-We have made an effort to provide nominal subtypes for every expression, I
-believe, so the nominal subtype would seem to work uniformly.
-
-I suppose once we go to the idea of an implicitly declared local Update
-procedure, it would seem natural to go to an implicitly declared Update
-procedure at the point of each operator declaration. E.g.:
-
- function "*"(Left : T; Right : T2) return T;
-
-would implicitly declare
-
- procedure "*"'Update_Operation(Left : in out T; Right : T2);
-
-with the obvious body.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, October 1, 2015 4:10 PM
-
-...
-> As long as we are only working with scalars,
-
-Tucker's proposal includes :&, and I'd be pretty surprised to find out that
-arrays are now scalar. ;-)
-
-On top of which, this works with user-defined operators, and they could be
-of any types. (I have a universal math package that uses controlled tagged
-types. That should map here, too.)
-
-****************************************************************
-
-From: Steve Baird
-Sent: Thursday, October 1, 2015 4:15 PM
-
->> It doesn't make much difference, but why wouldn't you want to use the
->> same parameter subtype that is already used for other predefined
->> operators (e.g., "+")?
->
-> Perhaps because the operator you are calling might not be predefined.
-
-You haven't convinced me, but it is a minor point in any case.
-
-If we settled the question via a coin flip, that would be fine with me.
-Since either choice is fine with me and you have a strong preference for one
-over the other, then that's good enough for me.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, October 1, 2015 4:21 PM
-
-...
-> I suppose once we go to the idea of an implicitly declared local
-> Update procedure, it would seem natural to go to an implicitly
-> declared Update procedure at the point of each operator declaration.
-> E.g.:
->
-> function "*"(Left : T; Right : T2) return T;
->
-> would implicitly declare
->
-> procedure "*"'Update_Operation(Left : in out T; Right : T2);
->
-> with the obvious body.
-
-Danger, Will Robinson. It would seem possible for the "Update_Operation" to
-end up with differing visibility than the associated operator, especially in
-a generic specification. (Renames to/from operators would also would be
-interesting.) [We had/have lots of trouble with that for "/=".]
-
- generic
- type T1 is (<>);
- type T2 is (<>);
- package G is
- function "*"(Left, Right : T1) return T2;
- -- No ":*" defined here (The types of Left and the result are different).
- end G;
-
- package I is new G (Integer, Integer); -- ":*" defined or not?? Explain your answer. :-)
-
-This also makes it inevitable that these would allow redefinition. I can
-(barely) stomach the idea of these at all, redefinition is going miles too far.
-(Especially as we don't allow redefinition of ":=", why is it suddenly OK if
-an operator is involved??? We'd have to allow redefinition of ":=" as well,
-else the model would be nonsense to most programmers.)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, October 1, 2015 4:57 PM
-
-> ...
->> I suppose once we go to the idea of an implicitly declared local
->> Update procedure, it would seem natural to go to an implicitly
->> declared Update procedure at the point of each operator declaration.
->> E.g.:
->>
->> function "*"(Left : T; Right : T2) return T;
->>
->> would implicitly declare
-
-I should have said "implicitly define"
-
->>
->> procedure "*"'Update_Operation(Left : in out T; Right : T2);
->>
->> with the obvious body.
->
-> Danger, Will Robinson. It would seem possible for the
-> "Update_Operation" to end up with differing visibility than the
-> associated operator, especially in a generic specification. (Renames
-> to/from operators would also would be
-> interesting.) [We had/have lots of trouble with that for "/=".] ...
-
-Sorry, I probably shouldn't have said it was implicitly "declared." I really
-meant it was implicitly *defined*. I used the Attribute_Reference syntax to
-indicate there was no "visibility" required. Merely that once you have
-identified the "*" operator, you call the associated implicitly *defined*
-update operation.
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
-
-****************************************************************
-
-From: John Barnes
-Sent: Thursday, October 1, 2015 1:10 AM
****************************************************************
Questions? Ask the ACAA Technical Agent