GNAT and user-defined aspects and pragmas?

GNAT and user-defined aspects and pragmas?

[Jacob Sparre Andersen]

I wanted to experiment a bit with user-defined aspects to see how far
GNAT takes LRM 13.1.1(38/3).

GNAT GPL 2014 (20140331) accepts certain implementation-defined aspects
(such as "SPARK_Mode"), but it doesn't accept user-defined aspects.

Unlike this, pragmas don't have to be known by the compiler in advance
to be accepted by GNAT (but you do get a warning if the pragmas aren't
recognised).

+ Why this difference?

+ Is it different in GNAT GPL 2015?  (I haven't gotten around to install
  it yet.)

+ Will it be different in GNAT GPL 2016?

Greetings,

Jacob
-- 
"I Am The Leading Programmer" - J.-P. Rosen
 is abstract tagged limited private

Re: GNAT and user-defined aspects and pragmas?

[Dennis Lee Bieber]

On Tue, 10 Nov 2015 14:28:06 +0100, Jacob Sparre Andersen <sparre@nbi.dk>
declaimed the following:

>I wanted to experiment a bit with user-defined aspects to see how far
>GNAT takes LRM 13.1.1(38/3).
>
	I see nothing in that paragraph which suggests anything of a "user
defined" capability.  

>GNAT GPL 2014 (20140331) accepts certain implementation-defined aspects
>(such as "SPARK_Mode"), but it doesn't accept user-defined aspects.

	38.a/3 explicitly states that unrecognized aspects are illegal. Between
the two, one gets the impression that if one uses aspects beyond those
defined by the language reference -- ie; using implementation defined
aspects -- one accepts that the result is not portable.

>
>Unlike this, pragmas don't have to be known by the compiler in advance
>to be accepted by GNAT (but you do get a warning if the pragmas aren't
>recognised).
>
	From the beginning (back in the days of mil-std 1815) pragmas were,
loosely, suggestions to the compiler -- they were not supposed to have any
effect on the correctness of a program (for example, Inline -- the program
should produce the same final result when executed whether a function was
inlined or not).

	I'll confess I've not studied the manuals (given that my current
employment is using Ada 83, and my previous employment was Ada 95) so I'm
not fully up on the last two significant change sets -- but I have the
impression that aspects have a higher significance: they are things that
must be done, not suggestions of things the programmer would like to have
done (pragmas). As a result, feeding one to a compiler, when it is not
known to that compiler, is an error.

>+ Why this difference?
>
>+ Is it different in GNAT GPL 2015?  (I haven't gotten around to install
>  it yet.)
>
>+ Will it be different in GNAT GPL 2016?
>
>Greetings,
>
>Jacob
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: GNAT and user-defined aspects and pragmas?

[Jacob Sparre Andersen]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
> On Tue, 10 Nov 2015 14:28:06 +0100, Jacob Sparre Andersen <sparre@nbi.dk>
> declaimed the following:
>
>>I wanted to experiment a bit with user-defined aspects to see how far
>>GNAT takes LRM 13.1.1(38/3).
>>
> 	I see nothing in that paragraph which suggests anything of a
> "user defined" capability.

Neither do I, but knowing how relaxed GNAT is with arbitrary pragmas, I
thought it was worth trying.

> 	38.a/3 explicitly states that unrecognized aspects are
> illegal.

Yes, un_recognized_ are illegal.  But unrecognised and unknown is not
quite the same thing.  I read 38.a/3 as a rule to enforce sensible
expression forms in aspect definitions, but that may be a too narrow
interpretation.

> Between the two, one gets the impression that if one uses aspects
> beyond those defined by the language reference -- ie; using
> implementation defined aspects -- one accepts that the result is not
> portable.

That's not the impression I've got from comments from ARG members here
on comp.lang.ada.  It is my impression that aspects should be open for
experimentation like pragmas have been, and that aspects are equivalent
to pragmas which are attached to a specific declaration.

With your interpretation, we wouldn't be able to compile SPARK 2014
programs with anything but GNAT - even when some of AdaCore's
competitors release an Ada 2012 compiler.

>>Unlike this, pragmas don't have to be known by the compiler in advance
>>to be accepted by GNAT (but you do get a warning if the pragmas aren't
>>recognised).
>>
> 	From the beginning (back in the days of mil-std 1815) pragmas
> were, loosely, suggestions to the compiler -- they were not supposed
> to have any effect on the correctness of a program (for example,
> Inline -- the program should produce the same final result when
> executed whether a function was inlined or not).

And aspects are (in my understanding) the subset of pragmas which refer
to a specific declaration, just with a nicer syntax.

> 	I'll confess I've not studied the manuals (given that my current
> employment is using Ada 83, and my previous employment was Ada 95) so
> I'm not fully up on the last two significant change sets -- but I have
> the impression that aspects have a higher significance: they are
> things that must be done, not suggestions of things the programmer
> would like to have done (pragmas). As a result, feeding one to a
> compiler, when it is not known to that compiler, is an error.

As Inline is also an aspect nowadays, I think your impression may be
wrong.

But there are subtle differences in the legality rules for pragmas and
aspects, which may explain why I don't have the same freedom to use
aspects for instructing external tools as I have with pragmas.

I would really like to hear from the ARG if the differences are
intentional.  Or if "Unrecognized aspects are illegal whether or not
they use custom syntax," actually refers to aspect_definitions and not
to aspect_names.

Greetings,

Jacob
-- 
"Three can keep a secret if two of them are dead."

Re: GNAT and user-defined aspects and pragmas?

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87d1vg3mvm.fsf@adaheads.sparre-andersen.dk...
...
>> Between the two, one gets the impression that if one uses aspects
>> beyond those defined by the language reference -- ie; using
>> implementation defined aspects -- one accepts that the result is not
>> portable.
>
> That's not the impression I've got from comments from ARG members here
> on comp.lang.ada.  It is my impression that aspects should be open for
> experimentation like pragmas have been, and that aspects are equivalent
> to pragmas which are attached to a specific declaration.

Certain ARG members are highly confused. :-) Nothing that is an aspect ever 
should have been a pragma, and aspects should be considered a replacement 
for pragmas rather than some sort of parallel syntax.

Ignoring an aspect is illegal as it is considered to be a critical part of 
the semantics of the program. Note that this follows the model for 
attributes and representation clauses. Ignoring unknown pragmas is a mistake 
in many instances (as Robert Dewar pointed out on several occasions). He 
gave examples like a pragma that sets up interrupts for some processor. That 
program might compile on some other implementation, but it won't work.

It's better to comment out unknown pragmas and aspects rather than to ignore 
them. Ada 83 got this wrong for pragmas (although one can find 
counter-examples where it's helpful).

> With your interpretation, we wouldn't be able to compile SPARK 2014
> programs with anything but GNAT - even when some of AdaCore's
> competitors release an Ada 2012 compiler.

Definitely. Since the SPARK aspects include some additional syntax, I can't 
see any way that it would be possible for a compiler that doesn't know about 
SPARK (say Janus/Ada) to compile a SPARK program. To the extent that SPARK 
annotations aren't significant to the semantics of the program, they 
probably should have been pragmas. But since AdaCore doesn't 
understand/believe in the difference, you'll have to remove them. That 
should be easy with a tool (it's a simple syntax transformation). [Of 
course, someone has to write the tool.]

                              Randy.

Re: GNAT and user-defined aspects and pragmas?

[Shark8]

On Thursday, November 12, 2015 at 12:24:28 PM UTC-7, Randy Brukardt wrote:
> 
> Certain ARG members are highly confused. :-) Nothing that is an aspect ever 
> should have been a pragma, and aspects should be considered a replacement 
> for pragmas rather than some sort of parallel syntax.

About the only instance where should-have-been-aspects-pragmas make any sense is with Import and Export. Things like, say, OpenGL with its half-million (slight exaggeration) definitions of Color, would be done cleaner with the single Pragma Import than individual aspects.

Re: GNAT and user-defined aspects and pragmas?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:46a5f0e0-50a5-4f11-b8cf-57f7f320fcd7@googlegroups.com...
On Thursday, November 12, 2015 at 12:24:28 PM UTC-7, Randy Brukardt wrote:
>
>> Certain ARG members are highly confused. :-) Nothing that is an aspect 
>> ever
>> should have been a pragma, and aspects should be considered a replacement
>> for pragmas rather than some sort of parallel syntax.
>
>About the only instance where should-have-been-aspects-pragmas make any
>sense is with Import and Export. Things like, say, OpenGL with its 
>half-million
>(slight exaggeration) definitions of Color, would be done cleaner with the 
>single
>Pragma Import than individual aspects.

Using overloading to cut down the number of pragmas one writes is precisely 
the kind of evil that aspects avoid. The problem is that usually you want 
all but one Color to be Imported, that one has it's own body to provide some 
Ada benefit (perhaps raising an exception, or using default parameters). And 
of course you have to search all of the source for a pragma, while an aspect 
is right on the declaration (since it changes the semantics of the 
declaration, it should be included as part of the declaration). [Overloaded 
routines also often need different link names for the different bodies, and 
that can't be done with a pragma, at least without jumping through hoops.]

In any case, Ada is not about decreasing the amount of typing one needs to 
do, it's about clearly expressing your intentions. Separating aspects from 
declarations does not help in such expressions.

                                       Randy.

Re: GNAT and user-defined aspects and pragmas?

[J-P. Rosen]

Le 12/11/2015 20:24, Randy Brukardt a écrit :
>> With your interpretation, we wouldn't be able to compile SPARK 2014
>> > programs with anything but GNAT - even when some of AdaCore's
>> > competitors release an Ada 2012 compiler.
> Definitely. Since the SPARK aspects include some additional syntax, I can't 
> see any way that it would be possible for a compiler that doesn't know about 
> SPARK (say Janus/Ada) to compile a SPARK program. To the extent that SPARK 
> annotations aren't significant to the semantics of the program, they 
> probably should have been pragmas. But since AdaCore doesn't 
> understand/believe in the difference, you'll have to remove them. That 
> should be easy with a tool (it's a simple syntax transformation). [Of 
> course, someone has to write the tool.]
Count me in!

(i.e.: I am preparing a new release of AdaSubst; adding that feature
would be really easy).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: GNAT and user-defined aspects and pragmas?

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	From the beginning (back in the days of mil-std 1815) pragmas
> were, loosely, suggestions to the compiler -- they were not supposed
> to have any effect on the correctness of a program (for example,
> Inline -- the program should produce the same final result when
> executed whether a function was inlined or not).

Import? Export? (OK, Ada95)

Re: GNAT and user-defined aspects and pragmas?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyd1vgkct0.fsf@pushface.org...
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>> From the beginning (back in the days of mil-std 1815) pragmas
>> were, loosely, suggestions to the compiler -- they were not supposed
>> to have any effect on the correctness of a program (for example,
>> Inline -- the program should produce the same final result when
>> executed whether a function was inlined or not).
>
> Import? Export? (OK, Ada95)

Those should never have been pragmas; they definitely don't fit under the 
model of pragmas as described above.

But since those are pragmas (and many other implementation-defined things 
like them), the notion that unknown pragmas can be ignored is fantasy. It's 
more harmful than helpful (which is probably why every Ada implementation 
that I know of has stern warnings for ignoring a pragma).

                                         Randy.

Re: GNAT and user-defined aspects and pragmas?

[J-P. Rosen]

Le 12/11/2015 20:27, Randy Brukardt a écrit :
> But since those are pragmas (and many other implementation-defined things 
> like them), the notion that unknown pragmas can be ignored is fantasy. 

Well, actually only /implementation defined/ pragmas can be ignored.
Language defined pragmas must be recognized, and are actually tested for
(as you probably know ;-) )

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr