* GNAT and user-defined aspects and pragmas? @ 2015-11-10 13:28 Jacob Sparre Andersen 2015-11-10 19:53 ` Dennis Lee Bieber 0 siblings, 1 reply; 10+ messages in thread From: Jacob Sparre Andersen @ 2015-11-10 13:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-10 13:28 GNAT and user-defined aspects and pragmas? Jacob Sparre Andersen @ 2015-11-10 19:53 ` Dennis Lee Bieber 2015-11-11 9:29 ` Jacob Sparre Andersen 2015-11-11 11:14 ` Simon Wright 0 siblings, 2 replies; 10+ messages in thread From: Dennis Lee Bieber @ 2015-11-10 19:53 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-10 19:53 ` Dennis Lee Bieber @ 2015-11-11 9:29 ` Jacob Sparre Andersen 2015-11-12 19:24 ` Randy Brukardt 2015-11-11 11:14 ` Simon Wright 1 sibling, 1 reply; 10+ messages in thread From: Jacob Sparre Andersen @ 2015-11-11 9:29 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-11 9:29 ` Jacob Sparre Andersen @ 2015-11-12 19:24 ` Randy Brukardt 2015-11-12 20:37 ` Shark8 2015-11-13 10:03 ` J-P. Rosen 0 siblings, 2 replies; 10+ messages in thread From: Randy Brukardt @ 2015-11-12 19:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-12 19:24 ` Randy Brukardt @ 2015-11-12 20:37 ` Shark8 2015-11-12 21:42 ` Randy Brukardt 2015-11-13 10:03 ` J-P. Rosen 1 sibling, 1 reply; 10+ messages in thread From: Shark8 @ 2015-11-12 20:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-12 20:37 ` Shark8 @ 2015-11-12 21:42 ` Randy Brukardt 0 siblings, 0 replies; 10+ messages in thread From: Randy Brukardt @ 2015-11-12 21:42 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-12 19:24 ` Randy Brukardt 2015-11-12 20:37 ` Shark8 @ 2015-11-13 10:03 ` J-P. Rosen 1 sibling, 0 replies; 10+ messages in thread From: J-P. Rosen @ 2015-11-13 10:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-10 19:53 ` Dennis Lee Bieber 2015-11-11 9:29 ` Jacob Sparre Andersen @ 2015-11-11 11:14 ` Simon Wright 2015-11-12 19:27 ` Randy Brukardt 1 sibling, 1 reply; 10+ messages in thread From: Simon Wright @ 2015-11-11 11:14 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-11 11:14 ` Simon Wright @ 2015-11-12 19:27 ` Randy Brukardt 2015-11-13 8:51 ` J-P. Rosen 0 siblings, 1 reply; 10+ messages in thread From: Randy Brukardt @ 2015-11-12 19:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GNAT and user-defined aspects and pragmas? 2015-11-12 19:27 ` Randy Brukardt @ 2015-11-13 8:51 ` J-P. Rosen 0 siblings, 0 replies; 10+ messages in thread From: J-P. Rosen @ 2015-11-13 8:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-11-13 10:03 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-10 13:28 GNAT and user-defined aspects and pragmas? Jacob Sparre Andersen 2015-11-10 19:53 ` Dennis Lee Bieber 2015-11-11 9:29 ` Jacob Sparre Andersen 2015-11-12 19:24 ` Randy Brukardt 2015-11-12 20:37 ` Shark8 2015-11-12 21:42 ` Randy Brukardt 2015-11-13 10:03 ` J-P. Rosen 2015-11-11 11:14 ` Simon Wright 2015-11-12 19:27 ` Randy Brukardt 2015-11-13 8:51 ` J-P. Rosen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox