!standard 13.4(1) 17-04-18 AC95-00290/00 !standard 13.5.1(1) !class Amendment 17-04-18 !status received no action 17-04-18 !status received 17-03-09 !subject Proposal for a simple language change !summary !appendix From: David J Etkins Sent: Thursday, March 9, 2017 2:39 PM Ada standards committee members: Would it be possible implement a change that allows an enumeration to be declared in a single statement like this without a separate use clause); type Color_Type is (White => 0, Yellow => 1, Blue => 3); The same with record representations, (i.e. combine the declaration and use clause into a single statement) type My_Rec is record Field1 : Integer at 0 range 0 .. 31; Field3 : String at 4 range 0 .. 63; end record; Seems like a simple enough change, and I am sure this has been suggested many times before. *************************************************************** From: Randy Brukardt Sent: Thursday, March 9, 2017 4:53 PM >Ada standards committee members: >Would it be possible implement a change ... Surely, changes are possible. :-) BTW, the following is my personal opinion which may not be representative of the entire group. ... > ... that allows an enumeration to be declared in a single statement > like this without a separate use clause); > > type Color_Type is (White => 0, Yellow => 1, Blue => 3); Maybe, but what problem is being solved? The Ada committee is primarily interested in solving problems that can't currently be solved. Ease of use matters, but only for commonly used features. ... > Seems like a simple enough change, and I am sure this has been > suggested many times before. Taking the second part first, I don't remember anyone ever proposing this in my 36 years working in Ada. I'm sure someone has (it seems obvious), but definitely not "many times". Secondly, there are no "simple enough changes". Every change takes a significant amount of time for wording creation, review, and has a non-zero impact on implementers. For instance, in this case, the enumeration representation clause is described in terms of an array aggregate. Clearly that wouldn't work unmodified here: either all of the rules that array aggregates bring to the table have to be duplicated somewhere, or all of the rules about declaring an enumeration type have to be rewritten to describe it as some unusual sort of array aggregate. Definitely a decent amount of work. And that would be only to help ease-of-writing (not ease-of-reading!) for a rarely used feature. (I've personally used it a handful of times outside of testing, all related to Win32 interfacing. Most of the time when it seems like it would be useful, it turns out that it is not, because you need to be able to combine the literals.) Thus, even if you believe the cost is low, the benefit is also low, so it's not at all obvious if even a small amount of work would be worth it. ... >The same with record representations, (i.e. combine the declaration and >use clause >into a single statement) Aside: A "use clause" is something else in Ada (see 8.4); what you're talking about is a record representation clause. When talking about Standards, preciseness is important! >type My_Rec is >record > Field1 : Integer at 0 range 0 .. 31; > Field3 : String at 4 range 0 .. 63; >end record; Unimportant aside: String is unconstrained and thus illegal as a record component. I'd suggest having used Long_Float (it has the right size). >Seems like a simple enough change, and I am sure this has been >suggested many times before. Again, I don't recall anyone ever having suggested this exact change. Tucker suggested something along this line, but mainly because it seemed to come for free with aspect specifications: type My_Rec is record Field1 : Integer with Position => 0, First_Bit => 0, Last_Bit => 31; ... But we didn't follow up on that because it's very verbose. As for "simple enough change", see above. And recall that one has to also be able to do this with discriminants, and discriminants are involved in conformance, so conformance would have to be updated to support this syntax. (And all of the existing wording would have to be generalized, most if it is specific to record representation clauses now.) Again, not a massive change, but definitely a non-trivial change. This is used more often in my experience, but again we have a trade-off between ease-of-writing and ease-of-reading. (Note: I believe your suggest hurts ease-of-reading by putting non-essential information into the record definition; that matters more for realistic record definitions than the toy ones that tend to populate these kinds of suggestions. That's because most real components have much lengthier subtype indications than "Integer", and many have default expressions and extensive comments as well; similarly, real record representation clauses often are more complex than just numeric literals. Putting them together would mean many 4 and 5 line component declarations, which would make the entire record declaration stretch across many pages.) And in any case, neither of these changes adds any capability at all. It's questionable whether we should spend some of our limited ability to make changes on things that are purely helping the ease-of-use for some features that aren't used that often. In any case, my opinion here isn't the last word. Let's see what others have to say. *************************************************************** From: Bob Duff Sent: Thursday, March 9, 2017 8:24 PM > In any case, my opinion here isn't the last word. Let's see what > others have to say. I basically agree with Randy. *************************************************************** From: David J Etkins Sent: Friday, March 10, 2017 2:41 PM Thanks for your feedback, as you can see my only reason is to eliminate the need to type the definitions twice and make the representation part optional and include it if necessary. *************************************************************** From: Joey Fish Sent: Friday, March 10, 2017 4:57 PM As far as the suggestion goes, it would probably be easier for implementers to implement something like a "Forward [=> True]" / "Representation => True" attribute to allow the compiler to 'reserve' the values of an enumeration and/or layout of a record in the private area of a package -- essentially adding a 'loophole' to the freezing rules -- what you're suggesting, essentially combines declarations and representation-clauses, would require more than just syntax changes, as the (Enum_1 => 1, Enum_2 => 2, Enum_N => N) construct is an array-aggregate [as written] using members of a type which haven't yet been declared. {Granted, this could be handled easily enough in a recursive-descent parser where you could put this in the portion handling declarations.} ***************************************************************