!standard 1.1.3(0) 20-12-02 AC95-00337/00 !class Amendment 20-12-02 !status received no action 20-12-02 !status received 20-10-22 !subject Importance of "cosmetic" changes !summary !appendix From: Tucker Taft Sent: Thursday, October 22, 2020 8:02 AM Bob Duff mentioned that he was against wasting a lot of time making "cosmetic" changes to the RM, and for that reason voted against AI12-0399-1. I sympathize with this view, but on balance I think such "cosmetic" changes are actually pretty important in the long run. I believe there is an analogy with making changes to a house -- an architect friend told me that when he designed an extension to a house, one of the goals was that when someone entered the house when it was done, if they hadn't seen the house before, they couldn't tell what was the old part and what was the new part. I feel the same general goal should apply to a good language update. If you haven't seen a prior version, then when you look at the reference manual for the extended language, you shouldn't be able to tell what are the old features and what are the new features. One difference for Ada -- when we want to remove something, we actually move it into Annex J (effectively the dusty old "attic" of the language) rather than just putting it into a dumpster. Perhaps more importantly, a new user of Ada need not be aware of what parts of the language are brand new, and what parts have been there since the beginning. If they have an historical bent, they could look in Annex J, but as a new user they should probably completely ignore it. So I think the cosmetic changes ultimately simplify the process of understanding the reference manual, by making it more consistent, with the same idioms used in similar contexts. Your mileage may of course vary... *************************************************************** From: Tullio Vardanega Sent: Thursday, October 22, 2020 8:23 AM I sympathize with this view, which is way more welcoming with possible newcomers than we normally let the RM be. Granted, language vendors may have other, leaner&nicer user-oriented documents to offer, but the RM is the vendor-neutral one, which should help everyone. *************************************************************** From: Jeffrey Cousins Sent: Thursday, October 22, 2020 9:09 AM Yes. I think it helps the reader to give the impression that the RM is written by a single person. I appreciate Randy does a lot of editorial tidying up, but there are several different people feeding in wording. Hence my "specified True" versus "specified as True" question yesterday. It would also be nice to state a preference for "the aspect XYZ" or "the XYZ aspect", both are in use but recent changes seem prefer the former. *************************************************************** From: Richard Wai Sent: Thursday, October 22, 2020 11:07 AM Strongly agree! *************************************************************** From: Bob Duff Sent: Friday, October 23, 2020 7:38 AM > I feel the same general goal should apply to a good language update. > If you haven't seen a prior version, then when you look at the > reference manual for the extended language, you shouldn't be able to > tell what are the old features and what are the new features. I agree with that principle that almost all of the time. But we should keep in mind that overly strict adherence to that principle is what got us into the morass that is anonymous access types and dynamic accessibility checks. ARG should have either banished anonymous access to Annex J, or redesigned it properly, in 2005. Instead, we doubled down on dynamic accessibility checks, turning a minor language design flaw into a colossal language design blunder. But yeah, the principle you stated is usually a good goal. Should it apply to changing pragmas to aspects? Seems like a lot of work for little gain, but I don't really care that much. ***************************************************************