Re: Ada 2012 Corrigendum

[Shark8 <OneWingedShark@gmail.com>]

Here's what I have so far; suggestions?

-----------------------------------------------------------------------
Issue 1:	Private Representation-Clauses and Subtypes Cannot be
  		Declared Together

!topic		Representation-Clause / Subtype Interaction
!reference	None [?]
!from		Edward Fish, 12 Sep 14
!keywords	Enumeration Representation Freezing Subtypes

Given an enumeration which has values associated with it via a 
representation clause the current freezing rules require that the 
representation-clause appear before a subtype of that type -- it would 
be desirable to be able to 'hide' the representation-clause in the 
private section to prevent exposure to the client systems of what is 
ultimately an implementation-detail.

For this I propose an aspect that would indicate to the compiler that 
there exists a representation-clause [in the private section] and 
therefore does not cause the subtype derivation to freeze that aspect 
(property) of the enumeration: "Delayed_Representation". (This aspect 
would only be needed for enumerations, though there conceivably could be 
reason to apply it to a private type and subtype [i.e. adding a 
Type_Invarient condition on the subtype].)

-------------------------------------------------------------------------------
Issue 2:	Static (and compile-time) Functions

!topic		Compile-time Executed Functions
!reference	None [?]
!from		Edward Fish, 12 Sep 14
!keywords	Compile-time Static Pure Functions Macro

Given the advent of expression-functions, and the loosening of 
'Function' from the more mathematical concept [that is, allowing IN OUT 
parameters] it makes some sense to introduce an aspect [or set of 
aspects] that re-introduces [and strengthens] the guarantees that were 
implicit (or initially intended) in the language. (Originally, the 
intent for functions was more along the lines of mathematical purity, 
but this was deemed to be too restrictive in Ada's initial design.)

In the following paper on Endian-Independence, several mathematical 
formulae are given for calculating the bits of elements [for 
representation-clause use] which could be used directly given the proper 
assurances: function purity, statically computed at compile-time.
( 
http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf )

We are prevented from declaring a function that computes one of the 
formula therein by limitations which need not exist (the very properties 
the aspects mentioned above would address).

With System;
Use  System;

Function MSB (N : Integer) Return Integer
with PRE_COMPILE -- or STATIC, or PURE_FUNCTION, or whatever
is (
  Boolean'Pos(Default_Bit_Order = Low_Order_First) * (N-1)
  );

  -- These constants could/should be folded into the functions
  -- that use them; however, that would likely hurt the readability
  -- (and therefore effectiveness) of the example.
Rightward_One_Bit : constant :=
	1 – 2 * Boolean'Pos(Default_Bit_Order = Low_Order_First));
F1 : constant := (Rightward_One_Bit + 1)/2;
F2 : constant := (Rightward_One_Bit - 1)/2;

Function Start (Bit_1, Bit_2 : Integer) Return Integer
with PRE_COMPILE
is ( MSB(16) + Bit_1*F1 + Bit_2*F2 );

Function Stop(Bit_1, Bit_2 : Integer) Return Integer
with PRE_COMPILE
is ( MSB(16) + Bit_2*F1 + Bit_1*F2 );

would allow the functions to be used directly, as in the given example:

  -- for BE, F1 = 1, F2 = 0, and MSB16 = 0
for Sighting_Rec use
record
   Color   at 0 range MSB16 + 0*F1  + 2*F2  .. MSB16 + 2*F1  + 0*F2;
   Speed   at 0 range MSB16 + 3*F1  + 13*F2 .. MSB16 + 13*F1 + 3*F2;
   Heading at 0 range MSB16 + 14*F1 + 15*F2 .. MSB16 + 15*F1 + 14*F2;
end record;

would become:

for Sighting_Rec use
record
   Color   at 0 range	Start( 0,  2) .. Stop( 0,  2);
   Speed   at 0 range	Start( 3, 13) .. Stop( 3, 13);
   Heading at 0 range	Start(14, 15) .. Stop(14, 15);
end record;