From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,59d24b21703c2885
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Use of constants on EFA
Date: 1997/11/05
Message-ID: <dewar.878790777@merv>#1/1
X-Deja-AN: 287332234
References: <63qkmc$8va$1@uttwil.bodensee.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 878791250 2006 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-11-05T00:00:00+00:00
List-Id: <comp.lang.ada>


More on that rule, you quoted the rule as

<<Objects shall be defined as being constant if their value is fixed
throughout the execution of the software.>>

This is definitely stated positively, as a rule for when constant must
be used. It is impossible to derive from the above rule any requirement,
or even implication that "objects shall NOT be defined as being constant
if their value is NOT fixed throughout the execution of the software", to
deduce this from the above statement is simply faulty logic.

You are applying a rule about how to use constant within a scope that
is not derivable from the above rule, but is a reasonable extension of
it.

Actually, how about the following argument that your code does indeed
conform to the rule, and that the rule forces the use of constant in the
cases where you want it.

If you have block:

	declare
	   x : constant String := xxx
        begin
	   ...
        end;

then your customer complains that the value of the object x changes
from one execution of this block to another.

That is wrong, as soon as you leave the block the object x disappears.
When you reenter, a completely new object x is created that has nothing
whatsoever to do with the previous one. 

So multiple executions of this block correspond to multiple objects,
and each of these objects has the quality that its value is fixed from
the point of its creation to the point of its destruction, which is
a reasonable working definition of what is meant by throughout the
execution of the software.

After all consider the global case

  package x is
	y: integer;
        z : constant integer := 3;
	...
  end x;

Is it the case that z has the value from the beginning to the end of the
execution of the program? Certainly not. The object z does not exist until
its declaration is elaborated, i.e. at the point where you elaborate the
declaration of y (or any other packages that are elaborated before package
x), the object z does not exist, and certainly does not contain the value 3.

So in the global case, it is clear that the lifetime that is relevant is
the lifetime of the variable, not the lifetime of the program, and the same
principle applies in identical manner to the multiple objects created by
multiple invocations of a declare block.

Good luck in your fight to prevail here, you are definitely on the right
side of this issue!

Robert Dewar
Ada Core Technologies.