Version 1.1 of acs/ac-00290.txt

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

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

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


Questions? Ask the ACAA Technical Agent