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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0236-1.txt

--- ai12s/ai12-0236-1.txt	2018/01/27 03:04:57	1.2
+++ ai12s/ai12-0236-1.txt	2018/03/02 06:46:45	1.3
@@ -897,3 +897,348 @@
 
 ***************************************************************
 
+From: Tucker Taft
+Sent: Wednesday, January 31, 2018  9:00 AM
+
+[The following was in version /02 of this AI. - Editor.]
+
+> I am assuming another AI will define the semantics of:
+> 
+>    X: constant := expression; -- not as a named number!
+>    Y renames expression;
+> 
+> i.e. an object_declaration without a subtype_indication (must include 
+> "constant"), and an object_renaming_declaration without a subtype_mark 
+> (expression must denote a constant view).
+> 
+> That AI should contain the business about *typed declarative expression*,
+> which allows one to distinguish number_declarations from
+> object_declarations. ...
+
+I missed or have forgotten the discussion of "typed declarative expressions."
+Who has that AI? Perhaps such an expression should be a different syntactic
+construct, or at least have some kind of italicized prefix so it stands out
+in the syntax for constant_declare_item.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, January 31, 2018  2:16 PM
+
+> I missed or have forgotten the discussion of "typed declarative 
+> expressions."  Who has that AI?
+
+I had forgotten also.  I looked it up in the minutes when I was writing the 
+latest version of this AI.
+
+> ...Perhaps such an expression should be a different syntactic 
+> construct, or at least have some kind of italicized prefix so it 
+> stands out in the syntax for constant_declare_item.
+
+Sounds reasonable.
+
+> > I am assuming another AI will define the semantics of:
+> > 
+> >    X: constant := expression; -- not as a named number!
+> >    Y renames expression;
+> > 
+> > i.e. an object_declaration without a subtype_indication (must 
+> > include "constant"), and an object_renaming_declaration without a 
+> > subtype_mark (expression must denote a constant view).
+> > 
+> > That AI should contain the business about *typed declarative 
+> > expression*, which allows one to distinguish number_declarations from
+> > object_declarations. ...
+
+I believe RaphaŽl volunteered for the above-mentioned AI.  I don't know if
+he's written it up, or if it has a number.
+
+I was thinking an object_renaming_declaration should have the same semantics
+(or as close as possible) whether it's inside a declare_expression, or not. 
+So if we allow the compiler to deduce the type from the renamed object, it
+should work the same in both cases.
+
+I removed a bunch of verbiage about it from THIS AI, which RaphaŽl might want
+to copy (from the old version).
+
+Similar comments apply to the syntax "X: constant := expression;".
+That's a bit tricky, because what is now a named number should keep the same
+semantics.  But I was hoping to allow "X: constant := Y;" where Y is of (say)
+a private type, and X is deduced to be of the same type.
+Both in a declare_expression, and as a normal declaration.
+
+I'm not sure we discussed the "constant" part, but I think it would be really
+weird to do other than I described above.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 31, 2018  5:55 PM
+
+> I missed or have forgotten the discussion of "typed declarative 
+> expressions."  Who has that AI?
+
+My understanding of the discussion in Lexington is different than Bob's, so I
+think it belongs in *this* AI. See below.
+
+> Perhaps such an
+> expression should be a different syntactic construct, or at least have 
+> some kind of italicized prefix so it stands out in the syntax for 
+> constant_declare_item.
+
+A "typed declarative expression" is an expression that allows the omission of
+the type name in a constant declaration. I think requiring a special form
+would rather defeat the purpose (allowing shorter specification of constants
+in declare exprs).
+
+> > Here is a new version of AI12-0236-1 declare expressions.
+> > This completes my homework.
+> > ...
+> > I am assuming another AI will define the semantics of:
+> > 
+> >    X: constant := expression; -- not as a named number!
+> >    Y renames expression;
+> > 
+> > i.e. an object_declaration without a subtype_indication (must 
+> > include "constant"), and an object_renaming_declaration without a 
+> > subtype_mark (expression must denote a constant view).
+
+My recollection of the Lexington discussions was that we wanted this generally
+*only* for renames expressions, and for those, omitting the type would always
+be allowed, assuming of course that the "name" resolves without context.
+
+In particular, we did not want to allow the omission of the type name for
+constant declarations, because of confusion with named numbers and because
+of the violation of a principle that anything declared has a nominal subtype.
+I note that the homework item for Raphael states that is about dropping type
+names for renames declarations; it isn't about doing that more generally.
+
+> > That AI should contain the business about *typed declarative 
+> > expression*, which allows one to distinguish number_declarations 
+> > from object_declarations. ...
+
+We didn't want to do that; the "typed declarative expression" was simply about
+whether the subtype name could be omitted. I thought we had decided to drop that
+business in favor of pure resolution (that is, if the expression can be resolved
+without any context, you can drop the subtype name) in the case of "constants"
+in declarative expressions.
+
+Perhaps I didn't get this recorded well enough in the minutes; my excuse would
+be it was the last AI we discussed in Lexington and I probably was more
+interested in getting the meeting over with than perfect note-taking.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, January 31, 2018  7:46 PM
+
+> My understanding of the discussion in Lexington is different than 
+> Bob's, so I think it belongs in *this* AI. See below.
+
+Probably your (Randy) understanding of the discussion is more accurate than
+mine.
+
+But it still seems to me that when it comes to inferring the type of an
+object, we should make renamings and constants work the same, and we should
+make these things work the same inside declare_expressions and as regular
+declarations.
+
+For ex., it would seem really weird to me if "X: constant := Y;" is a named
+ number in one context but not in the other.
+
+Likewise, it would seem weird if (assuming only one visible function F),
+"X: constant := F(Y);" can't resolve whereas "X renames F(Y);" can (as a
+regular decl not in a declare_expr).
+
+> Perhaps I didn't get this recorded well enough in the minutes; my 
+> excuse would be it was the last AI we discussed in Lexington and I 
+> probably was more interested in getting the meeting over with than 
+> perfect note-taking.
+
+Perhaps, but I bow down to your superior note-taking abilities.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 31, 2018  8:27 PM
+
+...
+> For ex., it would seem really weird to me if "X: constant := Y;" is a 
+> named number in one context but not in the other.
+
+I'd prefer that static expressions were properly declared always (i.e.
+keyword "static" in place of "constant"), and thus that there is no such thing
+as a named number, but it's 40 years too late to get rid that.
+
+> Likewise, it would seem weird if (assuming only one visible function F),
+> "X: constant := F(Y);" can't resolve whereas "X renames F(Y);" can (as 
+> a regular decl not in a declare_expr).
+
+I understand your point, but...
+
+The subtype name in an object renames is (arguably) actively harmful, because
+the subtype parts (constraint, exclusions, predicates) are completely ignored.
+Therefore, I can support dropping it; omitting it can't be more confusing than
+having it and still having to ignore most of its properties. It's likely to be
+clearer to force one to look at the original object to find the properties.
+
+The reverse is true for constant declarations: the nominal subtype given in
+the declaration is important -- it even determines the semantics of the
+constant declaration. Omitting it is just going to confuse readers; it's hard
+to figure out the nominal subtype of an expression in general.
+
+If I was running the circus (to steal one of your favorite sayings, and
+ignoring that in some sense I *am* running this circus :-), I'd follow your
+principle and not allow dropping the subtype name anywhere from a constant
+declaration. (I'd also consider making a keyword "static" that could be used
+in number declarations -- optionally, for compatibility, sigh -- and allow a
+number declaration to have an expression of any type that can be static.
+
+That would be especially useful if we allowed user-defined static types and
+operations, but it appears that we're not doing that. End rather unrelated
+tangent.)
+
+However, everyone that really wants declare expressions also wants to be able
+to write them without as much text as possible, so I'm willing to allow
+dropping the subtype name there -- a constant in a declare expression is much
+more like a renames than it is an object declaration (especially if it is of a
+composite type) -- I hope we're not requiring copying here as we do for "real"
+constant declarations. Anyway, I'm trying to understand others concerns here
+and be flexible so long as that doesn't require making a hash out of basic Ada
+principles.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Thursday, February  1, 2018  9:14 AM
+
+> The subtype name in an object renames is (arguably) actively harmful, 
+> because the subtype parts (constraint, exclusions, predicates) are 
+> completely ignored. Therefore, I can support dropping it; omitting it 
+> can't be more confusing than having it and still having to ignore most 
+> of its properties. It's likely to be clearer to force one to look at 
+> the original object to find the properties.
+
+I agreed about renamings.
+
+> The reverse is true for constant declarations: the nominal subtype 
+> given in the declaration is important -- it even determines the 
+> semantics of the constant declaration.
+
+I don't see what the big deal is.  We just need to define what the nominal
+subtype is, in the case of this new syntax (because obviously it's not
+explicit in the constant decl).
+
+I can think of several rules.  Perhaps: the nominal subtype is the subtype of
+the init expr, except if that has discrims, in which case it's the
+unconstrained subtype (and similar for arrays).
+
+> If I was running the circus (to steal one of your favorite sayings, 
+> and ignoring that in some sense I *am* running this circus :-),...
+
+I didn't make it up.  I got it from Steve, who got it from "If I Ran the
+Circus", by Dr. Seuss.  You can pick up a copy here for $200.00:
+
+https://www.biblio.com/book/i-ran-circus-seuss-dr-theodore/d/996641864?aid=frg&utm_source=google&utm_medium=product&utm_campaign=feed-details&gclid=EAIaIQobChMI9p3s2f6E2QIV2LXACh1LJw09EAQYASABEgLhzfD_BwE
+
+>...I hope we're not requiring copying here as we do  for "real" 
+>constant declarations.
+
+On the contrary, I assumed it would copy (unless of course the compiler can
+prove it doesn't matter).  It would be confusing to have different semantics
+in declare_expressions than for "real" constant decls.
+
+Isn't the whole point of allowing both constants and renamings is to let you
+choose "constant" semantics or "renaming" semantics?
+
+***************************************************************
+
+From: Bob Duff
+Sent: Thursday, February  1, 2018  9:23 AM
+
+> I don't see what the big deal is.  We just need to define what the 
+> nominal subtype is, in the case of this new syntax (because obviously 
+> it's not explicit in the constant decl).
+
+If we allow missing subtype indication ONLY in declare_exprs, we STILL need to
+define "nominal subtype", right?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 1, 2018  7:22 PM
+
+...
+> > The reverse is true for constant declarations: the nominal subtype 
+> > given in the declaration is important -- it even determines the 
+> > semantics of the constant declaration.
+object------------------------^
+> 
+> I don't see what the big deal is.  We just need to define what the 
+> nominal subtype is, in the case of this new syntax (because obviously 
+> it's not explicit in the constant decl).
+
+I didn't make my point very well (and the typo above doesn't help). The
+*reader* of the constant declaration needs to see the nominal subtype because 
+it matters in various other places.
+
+I often find myself searching for a subtype name in order to write a "use
+type" clause. That requires finding the declaration (annoying enough,
+especially if it is in a different file) and then extracting the type name
+(use clauses could complicate that step, but I rarely use them on type names
+anyway). If the type name isn't there, either, it could get very frustrating.
+
+Leaving subtype names out - anywhere - makes it hard on the readers. I was 
+willing to do that for very short-lived entities, because they're not likely
+to be used in a way where the subtype really matters. Things that potentially
+live for a very long time (the entire life of the program) must never omit the
+subtype name.
+
+I'm only willing to do so for renames because (A) the subtype name given is a
+lie anyway, properties come from the original object; and (B) renames is
+rarely used in the code I've seen.
+
+I'd prefer to see less optional stuff in Ada, not more. (Initializers [with <>
+meaning explicit no initialization], ending ids, parameter modes all should be
+required always). Obviously can't do that because of compatibility, but I
+definitely don't want to go in the wrong direction here.
+
+>>...I hope we're not requiring copying here as we do  for "real" 
+>>constant declarations.
+
+>On the contrary, I assumed it would copy (unless of course the compiler 
+>can prove it doesn't matter).  It would be confusing to have different 
+>semantics in declare_expressions than for "real" constant decls.
+
+You're right about this, but...
+
+>Isn't the whole point of allowing both constants and renamings is to 
+>let you choose "constant" semantics or "renaming" semantics?
+
+I thought it was because Steve thought he needed more never-used cases for
+his Bairdian execution examples. :-)
+
+There aren't a lot of good uses for renames (did you know that a rename
+actually makes the code worse in Janus/Ada? It prevents the name from getting
+evaluated in the a register, forcing extra memory writes). I wouldn't miss
+them if they didn't exist at all.
+
+OTOH, the idea of adding nested masters in the middle of expressions seems
+like a whole new level of unnecessary pain. Pain which becomes required if you
+allow/require copying of composite objects in declare expressions.
+(Can't have an object disappearing without being finalized!) For Janus/Ada,
+his means a thumb and a storage pool for each declare expression (plus the 
+composite objects); the ability to "ignore" these scopes would be eliminated.
+
+I was imagining that these objects would get assigned to temporaries (usually
+registers) and would never be materialized at all. That's not possible for
+composite objects (if real). The original proposal (which gave rename
+semantics to these guys) had the appropriate properties.
+
+I'm now thinking that we should only allow renames in declare exprs; that
+would fix any pressure to drop the subtype names from constants. "Constant"
+and copying is OK for elementary types in declare exprs, but that's it. And
+that seems like a wart.
+
+***************************************************************
+

Questions? Ask the ACAA Technical Agent