CVS difference for ai12s/ai12-0079-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0079-1.txt

--- ai12s/ai12-0079-1.txt	2017/06/13 00:47:50	1.8
+++ ai12s/ai12-0079-1.txt	2017/08/08 03:49:08	1.9
@@ -872,7 +872,7 @@
 ****************************************************************
 
 From: Tucker Taft
-Sent: Monday, June 12, 2016  6:26 PM
+Sent: Monday, June 12, 2017  6:26 PM
 
 Sorry to be so late.  Hopefully Randy is still in Wisconsin.  [This was version
 /04 of the AI.] I switched over to using in, in out, out.   I now require the
@@ -887,7 +887,7 @@
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Monday, June 12, 2016  7:48 PM
+Sent: Monday, June 12, 2017  7:48 PM
 
 Generally looks good. Some free association:
 
@@ -912,5 +912,190 @@
 surrounding by *s). [BTW, wouldn't it be better to call this a "global object
 set", since some constants are included? Rather than telling people to "ignore"
 the possibility of a constant being included? Why lie if you don't have to?]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 13, 2017  3:54 AM
+
+> (1) Not sure why you have "OLD STYLE" and "NEW STYLE" grammars. It 
+> just looks confusing. "Old Style" is cheap beer, not something that 
+> belongs in an AI. ;-)
+
+I left it there purely for comparison.  Initially I thought I would keep the
+old style as an option, but ultimately decided to fix all the wording to
+presume we go with the new style.  So  better would probably be to put the
+OLD STYLE stuff in the !discussion or the !proposal.
+
+> (2) The "New Style" grammar contains "proof" explicitly like a 
+> reserved word. Are you proposing a new reserved word, to fight about 
+> unreserved keywords yet again (this seems like a perfect use for such 
+> a thing), or something else??
+
+Good question.  Perhaps it should just be "<identifier> IN” from a syntax
+point of view, where <identifier> is either “proof” or some
+implementation-defined identifier.
+
+> (3) "/object_/name identifies the specified global variable (or
+> non-preelaborable constant, which is ignored for the purposes of the
+> remaining rules)" I'm not sure "ignored" is the right way to put this. 
+> I think you're trying to say that the possibility of non-preelaborable 
+> constants isn't mentioned in later rules. But that's a bit weird, 
+> because many of the later rules talk only about variables, and it 
+> would seem easy enough to talk about "objects", at least in the three 
+> following rules. Or maybe describe them as a term covering variables 
+> and non-preelaborable constants.
+
+I tried to do that and it just started getting really complicated.  So I
+punted and chose to allow a name that refers to a non-preelaborable constant,
+but otherwise ignoring it later.  I agree the wording needs work.  Perhaps
+better would be to just allow an implementation-defined extension to the
+syntax, and not talk about it further.  Non-preelaborable constants match
+pretty closely to what SPARK requires, but it is probably just confusing to
+give only part of that.
+
+> (4) Minor glitch: You ought to only italicize the defining occurrence 
+> of a term, you've got every occurrence of "global variable set" in 
+> italics (signified by surrounding by *s). [BTW, wouldn't it be better 
+> to call this a "global object set", since some constants are included? 
+> Rather than telling people to "ignore" the possibility of a constant 
+> being included? Why lie if you don't have to?]
+
+Sorry about that.  Yes I began to notice too many “*”s there, but didn’t have
+time to go back and decide what should be the defining occurrence.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 13, 2017  1:15 PM
+
+...
+> > (3) "/object_/name identifies the specified global variable (or 
+> > non-preelaborable constant, which is ignored for the purposes of the 
+> > remaining rules)" I'm not sure "ignored" is the right way to put this.
+...
+> I tried to do that and it just started getting really complicated.  So 
+> I punted and chose to allow a name that refers to a non-preelaborable 
+> constant, but otherwise ignoring it later.  I agree the wording needs 
+> work.  Perhaps better would be to just allow an implementation-defined 
+> extension to the syntax, and not talk about it further.
+> Non-preelaborable constants match pretty closely to what SPARK 
+> requires, but it is probably just confusing to give only part of that.
+
+I thought that just generally replacing "variable" by "object" in your wording
+(except the very first part) would work fine. I do agree that constants that
+can be modified (as we had a long debate about) ought to be included here, and
+I don't think there is any need to refer to SPARK to explain that. 3.3 is very
+clear that not all constants are really constant, and clearly this construct
+needs to include them. Referring to "variable" in formal Ada definitions is
+almost always wrong, other than in an actual assignment statement target.
+
+****************************************************************
+
+
+From: Florian Schanda
+Sent: Thursday, June 15, 2017  2:20 AM
+
+> Sorry to be so late.  Hopefully Randy is still in Wisconsin.  I 
+> switched over to using in, in out, out.
+
+I like the new syntax you propose, in a way we've come full circle (SPARK 2005
+used exactly these). However in SPARK 2014 we've used Input, In_Out, etc. for
+reasons of "its more like an aggregate that way" but I was never really happy
+with that reasoning.
+
+At the risk of asking a silly question, does proof in make sense as a
+parameter mode?
+
+Of course Tuck, if Ada adopts your syntax as its Global syntax then we're
+going to have a bit of fun in SPARK trying to make this backwards/forwards
+compatible. I suspect the SPARK extension will then just say "you can use
+Input as synonym for in, and you can't use both in the same global aspect,
+etc."?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 15, 2017  3:32 AM
+
+> ...
+> At the risk of asking a silly question, does proof in make sense as a 
+> parameter mode?
+
+I presume you mean for a subprogram.  If we go that route, it would seem to
+be similar to having a "ghost" parameter, in which case "ghost in" might be
+more appropriate than "proof in."  Perhaps we should make "ghost" into a
+reserved word, and allow it on subprograms and types where we currently allow
+"abstract" or "null," and in object declarations where the word "constant"
+or "aliased" might appear.
+
+> Of course Tuck, if Ada adopts your syntax as its Global syntax then 
+> we're going to have a bit of fun in SPARK trying to make this 
+> backwards/forwards compatible. I suspect the SPARK extension will then 
+> just say "you can use Input as synonym for in, and you can't use both 
+> in the same global aspect, etc.”?
+
+You will have to use "Input =>" as equivalent to "in".  The "=>" will be
+the most important discriminator, I think.
+
+****************************************************************
+
+From: Florian Schanda
+Sent: Thursday, June 15, 2017  8:19 AM
+
+> You will have to use "Input =>" as equivalent to "in".  The "=>" will 
+> be the most important discriminator, I think.
+
+There will be some pain to make sure this is not possible:
+
+with Global => (Input => X,
+                out X)
+
+or:
+
+with Global => (Input => X,
+                in Y)
+
+
+Do note that SPARK allows:
+
+with Global => X
+
+and
+
+with Global => (X, Y, Z)
+
+It may be worth to allow these as shorthands for the "in". It would also mirror
+parameters (missing mode = in) and really globals are a kind of parameter ;)
+
+Anyways, even with these difficulties I still think the new (yet old) style is
+better :)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 15, 2017  8:26 AM
+
+...
+> There will be some pain to make sure this is not possible:
+> 
+> with Global => (Input => X,
+>                out X)
+
+I think you should have a switch that you pass around when doing parsing to be
+in one of three states — uncommitted, committed to reserved-word modes,
+committed to non-reserved-word modes with “=>”.
+
+...
+> It may be worth to allow these as shorthands for the "in". It would 
+> also mirror parameters (missing mode = in) and really globals are a 
+> kind of parameter ;)
+
+I considered this and ultimately rejected it, as being a short-hand that just
+added complexity and ambiguity to the syntax, and only saved two characters.
+Yes I know “in” is optional in subprogram parameters, but there is much more
+context there.  Here all we have is a mode and a name, and I think omitting
+the mode is not helpful.  It is just too easy to interpret a missing mode as
+meaning “all access” (i.e. “in out”) rather than read-only access.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent