Version 1.1 of acs/ac-00337.txt

Unformatted version of acs/ac-00337.txt version 1.1
Other versions for file acs/ac-00337.txt

!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.

***************************************************************

Questions? Ask the ACAA Technical Agent