comp.lang.ada
 help / color / mirror / Atom feed
From: Jacob Sparre Andersen <sparre@nbi.dk>
Subject: Re: GNAT and user-defined aspects and pragmas?
Date: Wed, 11 Nov 2015 10:29:17 +0100
Date: 2015-11-11T10:29:17+01:00	[thread overview]
Message-ID: <87d1vg3mvm.fsf@adaheads.sparre-andersen.dk> (raw)
In-Reply-To: avh44b101hm5erus5s1tssc6ef7tj2g1qn@4ax.com

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


  reply	other threads:[~2015-11-11  9:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox