Ada 2012 Corrigendum

Ada 2012 Corrigendum

[Shark8]

Is it possible to add in new aspects, or no?

Two that I think would be useful would be:
(1) "Delayed_Representation" for enumerations which would allow the 
following, which is not currently possible due to freezing:

Package Ex1 is
   -- Statuses for drives.
   Type General_Status is (Unmounted, Standby, Ready, Busy, Unknown)
   with Delayed_Representation;

   -- Statuses for non-removable drives.
   Subtype HD_Status is General_Status range Standby..Unknown;

Private
   For General_Status use (
      Unmounted => 2#0000#,
      Standby   => 2#0001#,
      Ready     => 2#0011#,
      Busy      => 2#0101#,
      Unknown   => 2#1111#
    );
End Ex1;

(2) An aspect indicating a function which is not-only pure, but static 
-- intended to be computed at compile-time; this could, for example, be 
used to make the formulae in the endian-independent paper ( 
http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf ) 
directly usable.

Or should I submit these as AI entries? (In either case, what should I 
do to get these addressed?)

Re: Ada 2012 Corrigendum

[Peter Chapin]

On 2014-09-11 23:26, Shark8 wrote:

> (2) An aspect indicating a function which is not-only pure, but static
> -- intended to be computed at compile-time; this could, for example, be
> used to make the formulae in the endian-independent paper (
> http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf )
> directly usable.

It might be a good idea to review what C++ 2011 is doing with constexpr
if you want to go down a path like this. Any proposal of this nature
should take advantage of the whatever prior art exists in C++.

Peter

Re: Ada 2012 Corrigendum

[Dmitry A. Kazakov]

On Thu, 11 Sep 2014 20:26:35 -0700, Shark8 wrote:

> (2) An aspect indicating a function which is not-only pure, but static 
> -- intended to be computed at compile-time; this could, for example, be 
> used to make the formulae in the endian-independent paper ( 
> http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf ) 
> directly usable.
> 
> Or should I submit these as AI entries? (In either case, what should I 
> do to get these addressed?)

If you feel ready to formulate a comprehensive proposal, why not.

Handling endianness promoted in the paper is IMO wrong. [*]

Really important cases to consider are:

1. Handling static constraints. E.g. dimensioned arithmetic when the unit
is statically known. All operations must evaluate units statically by
static compile-time functions.

[ The proposal should cover conversion of exceptions in static computations
into compile-time errors. ]

[ The proposal should provide means to declare statically constrained
subtypes and objects with constraints evaluated at compile time from static
constraints of the arguments of a *non-static* operations. ]

Another example of this case is linear algebra package with matrix and
vector types. The static constraint here is the dimension.

2. Initialization of complex structures at compile time. E.g. instantiation
of a generic map with static keys and elements. Initialization of a
constant array of strings etc.

[ The proposal should cover the approach of handling compile-time dynamic
memory allocation and pools. A compile-time pool becomes a constant
initialized object at run-time. ]

[ The proposal should deal with compile-time type declarations, inheritance
and extension, as well as compile-time dynamic dispatch. ]

Good luck.

---------------------------
* For practical use the protocol always defines the exact endianness.
Furthermore, the host types need not to map onto the representations
"on-the-wire", it won't work in most real-life cases anyway.
Serialize/deserialize problem-space type approach is safer and easier to
implement.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada 2012 Corrigendum

[Robert A Duff]

Shark8 <OneWingedShark@gmail.com> writes:

> 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 [?]

You need at least one reference.

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

I'm afraid this isn't going to fly.  If it were feasible, then why would
you need an aspect?  You could just allow the rep clause to come later
than is currently allowed.  But I suspect it's not feasible.

Have you read the AARM annotations in 13.14?  You should, if you're
going to suggest changing the freezing rules.

For one thing, your suggestion violates 13.14(1.n).  You should at least
have an explicit argument as to why you think that's OK.  I don't know
if it violates any other parts 13.14 -- it's a lot of work to study the
freezing rules.

The freezing rules are extremely delicate, so I doubt ARG will want to
change them for a minor stylistic improvement.  Sure, it might be
stylistically better to put rep clauses in the private part, 
but it's hardly an important capability.

Ideally, there would be no freezing rules.  They are a language design
flaw.  Nobody understands them, and yet everybody trips over them.
The solution (decades too late) would be to NOT elaborate package
specs; package specs should be purely compile-time interface
definitions.  In that case, I think freezing rules would be
unnecessary.

One general piece of advice: Language changes are more likely to happen
if the person proposing them shows the exact wording changes to the RM.
But I realise that not everbody is fluent in the strange English-like
language in which the RM is written.  ;-)

- Bob

Re: Ada 2012 Corrigendum

[Robert A Duff]

Shark8 <OneWingedShark@gmail.com> writes:

> Issue 2:	Static (and compile-time) Functions
>
> !topic		Compile-time Executed Functions
> !reference	None [?]

Reference the section on static expressions, and possibly the
expression-functions section.

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

Well, Ada functions have never been pure mathematical functions.
They've always been allowed to read and write global variables,
heap data, etc.

You make a good argument that this suggestion would be useful,
but without actual RM wording, it's impossible to know exactly
what you are proposing.  For example, is this aspect allowed
only on expression functions?  If it's allowed on functions
with regular old bodies, what happens if the body contains
machine-code inserts?  If it's only allowed on expression
functions, then why do you need an aspect? -- you could just
say a call to an expression function is a static expression
if the function and its actual parameters have certain properties.
In fact, I think that idea was discussed when expression functions were
invented -- you might find it useful to read the AI that introduced
expression functions.

There must be some restrictions on what can go in these functions
(e.g. calls to other impure functions?).

What happens if you call one of these things with nonstatic actual
parameters?  I'd guess that should be legal, but that call won't
itself be a static expression.

Are these things allowed to have parameters/results of access type?
Composite type?

> Function MSB (N : Integer) Return Integer
> with PRE_COMPILE -- or STATIC, or PURE_FUNCTION, or whatever

I don't like "Pre_Compile" -- it seems too mechanistic.
Why not "Pure"?  "Pure_Function" already exists in GNAT,
and it means something different, so we wouldn't want to
use that name.

All in all, I suspect that this is too big of a change for the benefit.
It's not a bad idea, though, in the abstract.

- Bob

Re: Ada 2012 Corrigendum

[Shark8]

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;

Re: Ada 2012 Corrigendum

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcciokszmfo.fsf@shell01.TheWorld.com...
> Shark8 <OneWingedShark@gmail.com> writes:
>
>> Issue 2: Static (and compile-time) Functions
...
> In fact, I think that idea was discussed when expression functions were
> invented -- you might find it useful to read the AI that introduced
> expression functions.

Moreover, it also was reraised last year, and we have AI12-0075-1 for the 
issue. That's currently not planned for the Corrigendum, but one of the 
topics at this month's meeting is to revisit all of the future ideas and see 
if there are any that could and should be handled now. I'd not expect this 
one to be promoted, because the exact rules were never defined, just a lot 
of cases that need to be handled. (I think we'd only promote "shovel-ready" 
ideas, as the Corrigendum needs to be finished early next year; we're not 
going to have time to do a lot of discussion and revision on ideas.)

> There must be some restrictions on what can go in these functions
> (e.g. calls to other impure functions?).

Right. That's the hard part. The AI mentions things like the subtypes of the 
formal parameters and whether unused parameters participate in the 
correctness check. A good idea in the abstract, but the devil is in the 
details as always.

                                  Randy.