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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0187-1.txt

--- ai05s/ai05-0187-1.txt	2009/11/04 00:24:15	1.1
+++ ai05s/ai05-0187-1.txt	2009/11/04 06:26:38	1.2
@@ -465,3 +465,184 @@
 assignment.
 
 ****************************************************************
+
+From: Stephen Michell
+Sent: Tuesday, November 3, 2009  6:23 PM
+
+But I would say the same about +=, not worth the change to Ada.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 3, 2009  7:34 PM
+
+Well I must say that
+
+    X (A, B, G + 1) := X (A, B, G + 1) + 1;
+
+is pretty ugly, and the Ada way of getting around this is awfully heavy
+(declare block, now if we could just say in functional style something like
+
+    J := J + 1 where J = X (A, B, G + 1)
+
+that would be better (please don't think of this as a language suggestion :-))
+
+So to me
+
+   X (A, B, G + 1) +:= 1;
+
+is worthwhile, and trivial to learn, use and implement.
+
+I am dubious about the more general forms with <<>> or whatever ...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 3, 2009  7:48 PM
+
+I'm primarily concerned with implementation difficulty at this point.
+Implementers are having trouble keeping up.  Up to Ada 2005, even, and
+now we're talking about Ada 2012 or 2015 or whatever it's called.
+
+The "+=" thing is trivial to implement, as is the <<>> thing, whereas
+"if Grocery_List Contains Radishes" is probably not.
+
+But having said that, I could easily be convinced that none of this is
+worth the trouble!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 3, 2009  7:54 PM
+
+> Maybe the digraph <- could be used for this purpose:
+
+I like it!
+
+In a from-scratch language design, I'd prefer a keyword.
+How about the pronoun "it", as in "X[f(i)].Y := it + 1;"?
+But as I said, I'm opposed to new reserved words for this purpose.
+
+I can tolerate new reserved words, but only for something important.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 3, 2009  8:06 PM
+
+I still find this klunky compared to
+
+     X[f(i)].Y +:= 1;
+
+To me this notation takes care of the most common cases.
+
+Note by the way that the example
+
+     BLABLA := Next (BLABLA);
+
+is more easily handled (as in the GNAT sources), by just introducing an
+abstraction:
+
+     Next (BLABLA);
+
+which reads just fine, and indeed reads better than
+
+     BLABLA := Next (<-);
+
+or
+
+     BLABLA := Next (it);
+
+Whereas in the +:= case we are
+comparing
+
+     A +:= N;
+
+with
+
+     Increment (A, N);   (if we use procedural abstraction)
+
+or
+
+     A := <- + N;        (if we introduce a general
+     A := it + N;           language gizmo)
+
+and the +:= notation is better
+
+After all the whole business of infix operators is redundant, we can
+write:
+
+    "+" (1, 2);
+
+but we know that we want the +, because in this particular case, the
+functional notation is klunky.
+
+Much the same considerations apply to +:= and that's why it is
+reasonable to have a special case for infix operators in this situation.
+
+You don't want to generalize if the generalization has a negative effect
+on the 99% common use case, and helps only the remaining 1%.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 3, 2009  8:32 PM
+
+But that argues for *only* supporting +:= and forgetting the rest of the
+operators. None of the other cases are at all likely. And in any case,
+we aren't going to support all of the operators in this form:
+
+    **:= is ugly
+
+but the operators that are reserved words don't work at all. I surely
+hope we aren't going to allow stuff like:
+
+    mod:=
+    and:=
+
+and so on. Those aren't possible to lex in any reasonable way, and parsing
+doesn't have enough information (it doesn't see whitespace) to check the
+difference between "and:=" and "and :=".
+
+So, no matter what we do, we're going to have a very warty design if you
+just try to support this in assignment.
+
+I'm sympathetic to the concern about usability, but I really don't want to
+see an amazingly inconsistent design in Ada.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 3, 2009  8:33 PM
+
+I was thinking about it, (I mean "it")  but like you I don't think this small
+convenience deserves a new keyword. Maybe we should limit ourselves to op:= 
+syntax for the predefined binary operators, and not try to generalize this
+to the power of lambda expressions!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 3, 2009  8:54 PM
+
+It would be simplest to parse "<op>:="
+as two separate tokens, and allow white
+space between the operator and the ":="
+if that is what the user chooses to write.
+
+It doesn't seem so bad to write:
+
+   A(I) mod := 7;
+
+to mean
+
+   A(I) := A(I) mod 7;
+
+In some ways, it almost seems more elegant to
+write:
+
+    B(Z) + := 3;
+
+than to jam the two symbols together into "+:=".
+
+****************************************************************

Questions? Ask the ACAA Technical Agent