Re: Ada.Execution_Time

[Adam Beneschan <adam@irvine.com>]

On Dec 14, 9:45 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> writes:
>
> > Because Elaborate_All should never become a pragma. Two wrongs don't make
> > one right.
>
> Elaborate_All is a pragma because Elaborate is a pragma.  ;-)

And I guess Elaborate shouldn't have been a pragma, either, since it
affects the semantics; you can write a program that is not guaranteed
to work correctly unless you use this pragma.

When I was trying to look into whether such things really fit the
definition, I ran into trouble finding a clear non-language-specific
definition of what a "pragma" should be.  The Ada RM's have very clear
definitions.  In RM83: "A pragma is used to convey information to the
compiler".  That's crystal clear, except that in my view the entire
text of the program conveys information to the compiler, so it's not
really clear what distinguishes a "pragma" from any other line in the
source.  Ada 95 changed this to "A pragma is a compiler directive".
Which of course clears everything up.  Of course, my twisted mind
thinks an assignment statement is a compiler directive, since it
directs the compiler to generate code that assigns something to
something else, so I'm not sure that this is a useful definition.

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.  :) :) :)

And personally, I'm fine with that.  We can argue and discuss and
strive endlessly to come up with a flawless language; but during the
time it takes to perfect the language (and then for implementors to
implement it), everyone else is stuck using C++ and Java while they're
waiting for us, which cannot be good for the world.  So a bit of
artistic inelegance is, to me, a small price to pay.  I guess that's
because I'm too much of a ... well ... a pragma-tist?

                                   -- Adam