CVS difference for ai12s/ai12-0125-3.txt

Differences between 1.14 and version 1.15
Log of other versions for file ai12s/ai12-0125-3.txt

--- ai12s/ai12-0125-3.txt	2016/12/21 06:02:42	1.14
+++ ai12s/ai12-0125-3.txt	2016/12/22 03:29:34	1.15
@@ -3653,9 +3653,9 @@
 From: Bob Duff
 Sent: Sunday, October 9, 2016  8:28 PM
 
-> We had some sympathy for that, but generally wanted it to be a word 
+> We had some sympathy for that, but generally wanted it to be a word
 > chosen by the user.  E.g.:
-> 
+>
 >     This_Is_A_Very_Long_Name is VLN := VLN + 1;
 
 No, PLEASE don't do that.  It has to be a name or a symbol that is universally
@@ -3669,3 +3669,404 @@
 up Foo.  Referring to things by name is a cognitive burden.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, October 16, 2016  11:02 AM
+
+Now that it looks like we are going to go forward with "@" as the representative
+of the left-hand side, I would like ARG to consider allowing ":+" as syntactic
+sugar for ":= @ +" and corresponding interpretations of other binary operators.
+Although I appreciate the flexibility of "@" relative to a simple ":+" operator,
+I predict that 90%+ of all uses of @ will be immediately after ":=" and in front
+of a binary operator.   It seems a bit silly to require this sequence of special
+characters in many places in the code when a shorter sequence would do in almost
+all cases.  Because it is just syntactic sugar, it shouldn't open up any new
+issues of visibility, etc.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Sunday, October 16, 2016  11:11 AM
+
+A aargh!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, October 16, 2016  11:50 AM
+
+I'll take that as a rave... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, October 17, 2016  11:39 AM
+
+> Now that it looks like we are going to go forward with "@" as the
+> representative of the left-hand side, I would like ARG to consider
+> allowing ":+" as syntactic sugar for ":= @ +" ...
+
+And you were worried that @ looks like C?????
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, October 17, 2016  2:05 AM
+
+Indeed, that would be disgusting and mess up the whole point about the clarity
+of one big symbol.
+
+How much more messing about can this poor language take?  I will have to revise
+my book one day soon and I don't wnat to lie on my deathbed thinking that I
+ended up writing something disgusting.
+
+Grumpy old ...
+
+****************************************************************
+
+From: Florian Schanda
+Sent: Monday, October 17, 2016  7:01 AM
+
+Obvious question, why not '+=' which is what C, C++ and Python have chosen?
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, October 17, 2016  7:50 AM
+
+To maintain the same order of symbols as on a full assignment statement - colon
+before operator.
+
+****************************************************************
+
+From: Florian Schanda
+Sent: Monday, October 17, 2016  8:22 AM
+
+But ':=' is one token, not two right? "X : = 42" should really not parse...
+The '=' here is not really the equality equal, to me, but I guess I do see your
+point on some level.
+
+However, I maintain that '+=' is more "intuitive" because many other languages
+implement this. Beyond C, C++, Python; I understand also Java, Go (which
+incidentally also has :=), Rust, Swift, etc. all implement '+='.
+
+For Ada to have a different approach to this seems unwise.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, October 17, 2016  8:28 AM
+
+> Now that it looks like we are going to go forward with "@" as the
+> representative of the left-hand side, I would like ARG to consider allowing ":+" as syntactic sugar for ":= @ +"
+> and corresponding interpretations of other binary operators.
+
+I don't much like it.
+
+>...  Although I appreciate the
+> flexibility of "@" relative to a simple ":+" operator, I predict that
+>90%+ of all uses of  @ will be immediately after ":=" and in front of a binary operator.
+
+Yes, and that operator will be "+" approximately always.
+
+There's a big advantage to "@": it avoids duplicating a possibly-complicated
+left-hand side.  There is no such advantage to ":+".
+
+"@" is ugly, IMHO.  I'd prefer a word (possibly disguised if we're allergic to
+reserved words -- we discussed that).  Is it too late to fix the ugliness?  (If
+so, I'd still prefer to have the ugly feature -- usefulness should trump such
+aesthetic concerns.)
+
+In any case, I really don't like the idea of adding over a dozen more arcane
+symbols to Ada.  More junk to learn, and all it does is save 4 characters (two
+of which are spaces, so don't count). And they're all ugly (IMHO, of course).
+
+>...   It seems a bit silly
+> to require this sequence of special characters in many places in the
+>code when a shorter  sequence would do in almost all cases.  Because it
+>is just syntactic sugar, it shouldn't open up any new issues of visibility,
+>etc.
+
+I agree it's probably pretty easy to implement (in the compiler,
+pretty-printers, etc).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, October 17, 2016  8:31 AM
+
+> Obvious question, why not '+=' which is what C, C++ and Python have chosen?
+
+And while we're at it, we could violate hundreds of years of maths tradition,
+and use '==' for equality, just like C, C++, and Python have done.  It it were
+April Fool's Day, I'd propose that.  ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 17, 2016  8:44 AM
+
+> However, I maintain that '+=' is more "intuitive" because many other
+> languages implement this. Beyond C, C++, Python; I understand also
+> Java, Go (which incidentally also has :=), Rust, Swift, etc. all implement '+='.
+
+":=" in Go actually means declare and assign.  "=" is used for simple
+assignment.
+
+> For Ada to have a different approach to this seems unwise.
+
+It was the ambiguity about "/=" (divide-assign or not-equal) which helped to
+sink this proposal originally.  Not really much of a challenge to disambiguate,
+but still does create some cognitive dissonance.  Personally I could live with
+either, though the simplicity of simply "optimizing" out the "=@" combo when it
+appeared in sequence appealed to me. For what it is worth, I was not intending
+that you could write ": +".  ":+" would be a single lexeme, which would expand
+into three lexemes, namely ":= @ +".
+
+Apparently this whole idea does hit some people the wrong way, but to me it
+seemed to resolve the conflict between the additional power provided by "@" and
+the simplicity and familiarity (from other languages) of a simple "Add-to"/
+"Subtract-from" operation. Because it was intended to be pure syntactic sugar,
+it would eliminate the concerns about visibility which did make the original
+proposal for "+=" or ":+" admittedly more complex.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 20, 2016  2:58 PM
+
+> ... I would like ARG to
+> consider allowing ":+" as syntactic sugar for ":= @ +"
+> and corresponding interpretations of other binary operators. ...
+
+One usually imagines "syntactic sugar" as something that improves the
+understandability of the code. I think we need a name for cases where the syntax
+doesn't do anything other than add more cognitive overhead. Perhaps "syntactic
+celery"? :-)
+
+This case is definitely "syntactic celery".
+
+(1) It definitely looks like C to me, much more so than the '@' shorthand;
+(2) It requires additional lexical symbols, and either the first three character
+    symbols (which some tools may not be prepared to handle) or some unusual
+    wart as to the operators usable this way.
+(3) It saves precisely two characters of typing/reading (ignoring whitespace, as
+    that provides no additional reading overhead). Hard to imagine any mechanism
+    is worth eliminating two characters.
+(4) In the specific case of + (and -), there is a much more Ada-like syntax
+available: the attribute:
+    <obj>'Succ
+or  <obj>'Add (<expr>)
+That should have been less controversial than any of these other ideas (I'm
+still surprised that it was not).
+
+P.S. I'm reopening this wound for a procedural reason, see my next message.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 20, 2016  3:07 PM
+
+> Now that it looks like we are going to go forward with "@" as the
+> representative of the left-hand side, I would like ARG to consider
+> allowing ":+" as syntactic sugar for ":= @ +"
+> and corresponding interpretations of other binary operators.
+...
+
+Procedural question:
+
+Usually, our procedures have new proposals going through a "triage" system
+where Jeff and I consider the proposal and determine whether or not to give
+a proposal meeting time and a first-class hearing (that is, determine
+whether it is given an AI number).
+
+In this case, based on prior conversations with Jeff and his initial
+reaction to this proposal, and the fact that I cannot overstate my
+opposition to this idea, I'm pretty certain that we would stick it in the
+darkest place that we can find (AC-666 anyone?? :-).
+
+However, as past experience shows, it's quite possible that doing that would
+just double my work (by first making an AC and then having to convert it to
+an AI). So I put the question to the full group: do we have a motion and a
+second in favor of putting this proposal on the agenda?
+
+P.S. I ask for both a motion and second in order that anyone who's changed
+their mind about this proposal in subsequent discussion isn't automatically
+assumed to be in favor of putting it on the agenda.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, October 20, 2016  3:24 PM
+
+> However, as past experience shows, it's quite possible that doing that
+> would just double my work (by first making an AC and then having to
+> convert it to an AI). So I put the question to the full group: do we
+> have a motion and a second in favor of putting this proposal on the agenda?
+
+I suppose this means that negative votes donít count for this procedural issue,
+but in any case let me join you and Jeff in finding this proposal unpalatable
+("celery" indeed).
+
+By the way, the use of @ as an abbreviation for the LHS of an assignment is
+implemented in the current version of GNAT, test cases are welcome.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, October 20, 2016  4:22 PM
+
+> One usually imagines "syntactic sugar" as something that improves the
+> understandability of the code. I think we need a name for cases where
+> the syntax doesn't do anything other than add more cognitive overhead.
+> Perhaps "syntactic celery"? :-)
+>
+> This case is definitely "syntactic celery".
+
+Hey, I LIKE celery.
+
+The term "syntactic poison" was bandied about during Ada 9X.
+
+> (1) It definitely looks like C to me, much more so than the '@'
+> shorthand;
+
+I think :+ is ugly, and @ is also ugly.  (Nobody responded when I asked if it's
+too late to fix that.)
+
+But @ brings real value, which should trump aesthetic concerns, whereas :+
+brings negative value (IMHO, of course) -- it's ugly, it only saves a couple of
+characters, and it requires knowing about a whole bunch of new symbols.
+
+> (2) It requires additional lexical symbols, and either the first three
+> character symbols (which some tools may not be prepared to handle) or
+> some unusual wart as to the operators usable this way.
+
+I think that's a stretch.  If this feature were good, then updating tools would
+be worth it -- it's not rocket surgery.
+
+> (3) It saves precisely two characters of typing/reading (ignoring
+> whitespace, as that provides no additional reading overhead). Hard to
+> imagine any mechanism is worth eliminating two characters.
+
+Agreed.
+
+> (4) In the specific case of + (and -), there is a much more Ada-like
+> syntax
+> available: the attribute:
+>     <obj>'Succ
+> or  <obj>'Add (<expr>)
+> That should have been less controversial than any of these other ideas
+> (I'm still surprised that it was not).
+
+I don't think I'd support those, either.  Not so ugly, but still of little added
+value.
+
+> P.S. I'm reopening this wound for a procedural reason, see my next message.
+
+Seen.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, October 20, 2016  4:23 PM
+
+> Procedural question:
+
+I don't know what the written procedures say, but surely if more than one ARG
+member wants to discuss an issue, it should get on the agenda. I saw two people
+supporting Tuck's proposal (including Tuck). You and Jeff should not have veto
+power.
+
+>...So I put the question to the full group: do we have a motion and a
+>second in favor of putting this proposal on the agenda?
+
+I suppose you should take this email as such a motion.
+Or as a second to Tuck's motion?
+
+P.S. I am opposed to the :+ proposal.  But that doesn't mean it shouldn't be on
+the agenda.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, October 20, 2016  5:12 PM
+
+> But @ brings real value, which should trump aesthetic concerns,
+> whereas :+ brings negative value (IMHO, of course) -- it's ugly, it
+> only saves a couple of characters, and it requires knowing about a
+> whole bunch of new symbols.
+
+What he said.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 20, 2016  5:34 PM
+
+...
+> I think :+ is ugly, and @ is also ugly.  (Nobody responded when I
+> asked if it's too late to fix that.)
+
+You weren't at Pittsburgh. Tucker forced us to do that exercise. We wasted at
+least an hour looking at alternatives to @. Everything proposed had flaws that
+at least some people considered fatal. After a number of votes, we ended up
+where we started (with @). I don't think anyone really loves it, but everyone
+can live with it, which is better than any other alternative we looked at.
+You'll be able to read the gory details in the minutes when I get them done.
+
+> But @ brings real value, which should trump aesthetic concerns,
+
+Right. Which is why we decided again to stick with @. That's two meetings in a
+row (with different subsets of members) that reached the same conclusion. We
+decided that we would bring it to WG 9 separately so that it would get an
+individual vote.
+
+But apparently, Tucker wasn't done. Sigh.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Thursday, October 20, 2016  5:50 PM
+
+There is the fairness case for it being on the agenda, but all 3 flavours of 125
+are meant to be low priority, and several AIs that we should have discussed at
+Pittsburgh weren't because of the time spent revisiting 125, so it should come
+after them.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 20, 2016  8:18 PM
+
+> Right. Which is why we decided again to stick with @. That's two
+> meetings in a row (with different subsets of members) that reached the same conclusion.
+> We decided that we would bring it to WG 9 separately so that it would
+> get an individual vote.
+>
+> But apparently, Tucker wasn't done. Sigh.
+
+Well I agreed to not interfere with "@" being approved by WG9.  But then I
+thought we could accommodate both those who like the power of the "@" and those
+who like the convenience and familiarity of a simple "Add-To"/"Subtract-From"
+operation.  In any case, I asked ARG to "consider" it and it seems pretty clear
+that ARG thinks it is a dumb idea. So I won't be writing up an AI on it!
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, October 20, 2016  11:24 PM
+
+>> But @ brings real value, which should trump aesthetic concerns,
+>> whereas :+ brings negative value (IMHO, of course) -- it's ugly, it
+>> only saves a couple of characters, and it requires knowing about a
+>> whole bunch of new symbols.
+>
+> What he said.
+
++1
+
+I'd add that the only reason that I found @ acceptable (although not very
+enthusiastically) is that it would make :+ unnecessary...
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent