Re: Unreferenced lock variables

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <3718268c.48395643@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> Randy Brukardt was kind enough to educate me on some of
> the points here, including

> procedure Something(P : in integer) is
>   Unused : integer := P/0;
> begin ...

> which can legally have Unused eliminated and thus the
> divide by zero eliminated.  That certainly provides an
> analogous precedent for eliminating the controlled
> Initialize/Finalize.

This is a bad analogy. Yes, I know that some of the ARG
members used this to justify the position taken, but the
reasoning is faulty.

In the case of built-in language checks, the idea is to
prevent the program from doing something bad. In other
words a divide by zero is an error in your program, and
if it happens you want to know about it. We decided early
on in Ada 83 that it was OK to eliminate such exceptions
if the situation leading to the error can be safely
eliminated. There are three reasons here:

1) We really don't want the nice checking in Ada to damage
code generation unnecessarily. Programmers want to know if
a real error occurs, but they do not need to know EXACTLY
where a constraint error is raised, or to know about a
CE that in fact was not raised at all for good and sound
reasons.

2) If we eliminate the divide in a case like this, we
eliminate the error. So the idea of run time checks, to
check for errors is not violated by this optimization.

3) A correct program does not raise exceptions like this
anyway (if you use divide by zero as a normal case control
structure, you should be drummed out of the Ada community!)
This means that correct programs are not affected by these
kinds of optimizations.

Now the initialize/finalize case is TOTALLY different. None
of the above considerations applies. In fact this is the
thin end of a very dangerous wedge.

Here for the first time we have well defined behavior from
a program, which we know that existing programs sometimes
use for good reasons, and we suddenly introduce a new rule
which allows the optimizer to optionally change the
behavior of the program in a fundamental way that is
incompatible with what is in the RM.

This is not what I call an optimization!

Yes, there have been discussions of possible optimizations
in the case of temporaries created by the compiler, but
such temporaries are in some sense an artifact of the
implementation anyway. Here we are talking about a declared
variable, and it is 100% clear that the current RM requires
the initialize and finalize call.

Why the thin end of the wedge?

Because next someone will say

  X : Integer := Function_With_Side_Effects;

is allowed NOT to call the function if X is unused, and
away we go down the slippery slope.

A couple of further points here.

GNAT will most certainly NOT take advantage of this
optimization, it seems a bad idea.

If you have no user defined initialization routine, and
a finalization routine whose only purpose is to release
storage, then you can use the GNAT pragma

  pragma Finalize_Storage_Only (subtype_NAME);

which tells the compiler to omit the Finalize call if it
is not needed, e.g. at the outer level, or all the time in
a Java environment.

Such pragmas that control the behavior of the compiler are
legitimate, and I would have no objection to a pragma
saying

  pragma Omit_Initialize_Finalize_For_Unused;

but to allow this optimization without such a pragma is
to me a language change justified only by the hope that
an "optimization" will be significantly worth while (only
a hope, no quantitative data of any kind is available!)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own