Re: Ada.Execution_Time

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:10872143-12a2-4d25-bb08-e236b15d2c18@o14g2000prn.googlegroups.com...
...
>Even in Ada 83, there were at least three different flavors of
>pragmas.  Some (LIST, PAGE) had no effect on the operation of the
>resulting code.  Some (OPTIMIZE, INLINE, PACK) could affect the
>compiler's choice of what kind of code to generate, but the code would
>produce the same results (unless the code explicitly did something to
>create a dependency on the compiler's choice, such as relying on 'SIZE
>of a record that may or may not be packed).  And others (ELABORATE,
>PRIORITY, SHARED, INTERFACE) definitely affected the results---the
>program's behavior would potentially be different (or, in the case of
>INTERFACE, be illegal) if the pragma were missing.  I'm having trouble
>figuring out a common thread that ties all these kinds of pragmas into
>one unified concept---except, perhaps, that they are things that the
>language designers found it PRAGMAtic to shove into the "pragma"
>statement instead of inventing new syntax.  :) :) :)

I think you've got it. None of these things (in the last category) ought to 
have been pragmas in the first place.

Note that pragmas are one of the few ways that implementers have to 
represent implementation-defined information, so in practice, we have lots 
of things that ought to never have been pragmas.

At least Ada 2012 has finally come to grips with this, in that the aspect 
clause will be able to be used rather than almost all of the existing 
pragmas. (But not Elaborate, as the syntax doesn't work in a context clause, 
and no one has the energy to invent some other syntax solely for that 
purpose.) Note, however, that there will still be uses for the old pragmas 
(if you want to hide the aspects in the private part, for instance). But 
they should be used much less often.

                                      Randy.