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

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

--- ai05s/ai05-0187-1.txt	2009/11/04 06:26:38	1.2
+++ ai05s/ai05-0187-1.txt	2009/12/09 01:20:40	1.3
@@ -616,7 +616,7 @@
 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:= 
+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!
 
@@ -644,5 +644,561 @@
     B(Z) + := 3;
 
 than to jam the two symbols together into "+:=".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, November 4, 2009  7:10 AM
+
+> But that argues for *only* supporting +:=
+
+and of course -:= which is just as common
+
+> 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
+
+I would include all the operators, since it is trivial to implement them all.
+
+> 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 :=".
+
+I don't see any difficulty in implementation at all. There are two choices.
+
+Either you require no space in between the operator and the :=, in which case it
+is trivial to deal with mod:= etc in a lexical analyzer (I cannot even imagine
+what difficulty Randy is referring to .. ideed this rule would be similar to C,
+that you always parse out the longest token that matches.
+
+Or, you allow spaces in between the tokens in which case the parser can handle
+this just fine (there is no current legal code in which you can see mod and :=
+tokens adjacent, so no problems arise).
+
+You could even at least in GNAT require no spaces and handle it in the parser,
+since we keep source locations of all tokens (I am surprised at any compiler
+that does not do that), but in any case this third approach is inferior to the
+other two.
+
+So I see zero implementation difficulty here.
+
+> 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.
+
+I find allowing quite generally
+
+operator :=
+
+(with or without spaces allowed, I don't care), that doesn't seem warty. Any of
+the more general notations seem much less convenient with no compensatory gain.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, November 4, 2009  7:11 AM
+
+> In some ways, it almost seems more elegant to
+> write:
+>
+>     B(Z) + := 3;
+>
+> than to jam the two symbols together into "+:=".
+
+Seems reasonable to me, I would be quite happy to allow (but of course not
+require) spaces.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, November 5, 2009  11:15 AM
+
+Another possibility that may not have been considered:
+
+Instead of trying to come up with a shortcut for eliminating the first primary
+of the RHS, how about eliminating the LHS instead?
+
+e.g.
+
+X + 5;
+
+If one were asked what such a statement would do, it's pretty difficult to come
+up with anything other than:  Add 5 to X;
+
+X ** 2; -- Square X
+-X / 3.0;  -- Negate X and divide it by 3.0
+
+or
+
+X + 5 * 2 + f(Y);  -- Add 10 times the result of F to X.
+
+etc
+
+We wouldn't want to be able to say
+X = 2;
+
+of course, otherwise we would be introducing a bunch of C vulnerabilities such
+as confusion between comparison and assignment for =.
+
+However, if we were to define an assignment statement as;
+
+   assignment_statement ::= variable_name := expression; | assignment_expression;
+
+Then say that an assignment_expression is a simple_expression where the first
+primary is a variable_name, such that an assignment_expression is a shortcut
+for:
+  variable_name ::= assignment_expression where variable_name
+is the first primary of the assignment_expression;
+
+.Then, maybe this could work. This would allow all operators other than
+relational operators (= /= < > <= >=) and logical operators (and or xor).
+
+If we are open to approaching this in a non-C way, could this be viewed as
+perhaps better than C? Or are there syntactic problems that would rule out this
+approach?
+
+For example, I find;
+     X ** 2;
+easier to parse mentally than
+     X ** := 2;
+
+But perhaps that is just me.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Sunday, November 15, 2009  9:31 AM
+
+> Maybe the digraph <- could be used for this purpose:
+>
+> A.B := F (<-,  <-);
+>
+> A (X) := <- + 1;
+>
+> intuitively it hints at its purpose by pointing to the left-hand side in the
+> assignment.
+
+Intuitively it looks like a smiley and it can surely be used to construct some
+obfuscated source code:
+
+A := F((<-=><-*<-))**<-;
+
+FWIW, I agree with everything that RBKD said on this thread.  Please stick to
+what programmers expect (ie +:= by analogy to += in just about every language)
+and please support all operators (I certainly use |= and &= all the time in
+C++).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, November 16, 2009  5:20 PM
+
+> Intuitively it looks like a smiley and it can surely be used to
+> construct some obfuscated source code:
+>
+> A := F((<-=><-*<-))**<-;
+
+I don't buy the "can be used to obfuscate" argument.
+I only buy the "can be used to obfuscate, BY ACCIDENT" argument.
+
+By the way, I don't think the "<-" on the left-hand side of a "=>" in an
+aggregate would be legal, according to Gary's proposal (with Ed's modification
+that uses the "<-" syntax). We're not talking about some sort of macro
+substitution, here.
+
+> FWIW, I agree with everything that RBKD said on this thread.  Please
+> stick to what programmers expect (ie +:= by analogy to += in just
+> about every language) and please support all operators (I certainly
+> use |= and &= all the time in C++).
+
+So you've been writing a bit of C++ code lately, eh?  ;-)
+
+I prefer: Do nothing.
+
+Second choice: Do something, but make it fairly general --- a way to refer to
+the left-hand side of the assignment.
+
+Third choice: +:= and the like.  I agree that if we're going to do that, it
+should apply to all operators.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  11:52 AM
+
+> I prefer: Do nothing.
+
+A pity, since the third choice here would be useful both in making code easier
+to read and write.
+
+> Second choice: Do something, but make it fairly general --- a way to
+> refer to the left-hand side of the assignment.
+
+I find all the proposals of this nature highly distasteful. I would rather do
+nothing than introduce such a junky syntax.
+
+> Third choice: +:= and the like.  I agree that if we're going to do
+> that, it should apply to all operators.
+
+Such an easy and straightforward proposal, why not?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  11:53 AM
+
+> Second choice: Do something, but make it fairly general --- a way to
+> refer to the left-hand side of the assignment.
+
+Part of the reason I hate this, is that in practice the simple cases of
+operators will make up 98% of the use of this feature, and any general notation
+will make this common usage harder to write and read.
+
+Furthermore, the idea of having somethingf like a <- buried deep in an
+expression to mean the left hand side is
+
+a) obscure from a code understandability point of view
+b) annoying to implement, since it introduces a really odd context dependence.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 16, 2009  12:23 PM
+
+> I prefer: Do nothing.
+
+I strongly agree with Bob here. Three reasons for that:
+* Robert has made a strong enough case that what Bob calls the second choice
+  here would be hard to read and understand;
+* This Amendment is getting clogged full of everybody's "nice to haves"; we're
+  going to have to draw a line somewhere or this Amendment is going to get way
+  too large (or we're going to start dropping important stuff in favor of "nice
+  to haves", which is the wrong way to go);
+* Symbols like "and:=" are a lexical nightmare. Any way to recognize them
+  properly requires a distasteful hack to a lexer (and I think requiring later
+  parts of the compiler to know about whitespace between tokens is a distasteful
+  hack);
+* Ada is refreshingly free of special-case gizmos, and these C operators are the
+  worst kind, IMHO. Other than +:=, you'd hardly ever even remember to use them.
+
+P.S. Yes, I noticed I can't count. ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  1:17 PM
+
+> * Symbols like "and:=" are a lexical nightmare. Any way to recognize
+> them properly requires a distasteful hack to a lexer (and I think
+> requiring later parts of the compiler to know about whitespace between
+> tokens is a distasteful hack);
+
+This is a completely unconvincing argument.
+
+First the lexical issue is completely incomprehensible. It is absolutely trivial
+to deal with these in any reasonable lexer, and if you are using a lexer like
+flex, it is of course trivial (since there is a standard option, needed of
+course for C, to always recognize the longest token). If by some devious design
+your compiler cannot handle this, I don't see that design short-coming as having
+a legitimate influence here.
+
+Second, at least Tuck and I feel that it would be a mistake to require no white
+space, and that it is perfectly reasonable to allow:
+
+    X + := 3;
+
+and indeed may even read better
+
+> * Ada is refreshingly free of special-case gizmos, and these C
+> operators are the worst kind, IMHO. Other than +:=, you'd hardly ever
+> even remember to use them.
+
+Well -:= is of course just as common, but it is indeed for the overwhelminingly
+common cases of +:= and -:= that you use these constructs.
+
+I find nothing here that is a "special-case gizmo", this notation has been
+familiar for decades in Algol-68, and C languages, as well as those languages
+whose syntax is derived from C.
+
+On the contrary, I find it plain horrible to have to write
+
+    A (J, J, L + 3) := A (J, J, L + 3) + 1;
+
+and make the reader carefully compare the two references, and
+
+    declare
+       Elmt : Integer renames A (J, L, L + 3);
+    begin
+       Elmt := Elmt + 1;
+    end;
+
+is alwfully heavy.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, November 16, 2009  1:18 PM
+
+I think I agree with you Randy.
+
+But as far as the lexical issue, treating them as two separate tokens seems
+fine, so the white space would be optional between "and" and ":=" in "X and :=
+B;".  Neither the lexer nor the parser would have to jump through any hoops.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  1:27 PM
+
+That's my preference too, I definitely think that
+
+   A and := 16#FF#;
+
+reads as well or better than
+
+   A and:= 16#ff;
+
+particularly if your normal lexical style is to put blanks around all binary
+operators, as we do in GNAT, so we would always write
+
+   A := A and (expr);
+
+not
+
+   A := A and(expr);
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  1:28 PM
+
+> I think I agree with you Randy.
+
+Are you agreeing with the ordering  nothing > fancy version > simple version?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  9:31 AM
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent