Re: Ada 2012 Corrigendum

[Robert A Duff <bobduff@shell01.TheWorld.com>]

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