question regarding bound specs

[Ed Barkmeyer]

Liam Mullan wrote:

> my question regards the dynamic nature or otherwise of aggregate bound
> specs. The question is whether bound specs are evaluated just once (at
> the point of declaration), or whether the bounds change when variables
> involved in the bound expressions change.

Neither.  One must first realize that an Express model is a *static*
model of some information population.  The "dynamic" features of EXPRESS
are an accident of the (unfortunate) notation used to define the results
of FUNCTIONs.  There is no "runtime" evaluation of an EXPRESS function,
because there is no defined execution sequence for the set of data
instances that conforms to an EXPRESS model.  The interpretation of an
EXPRESS FUNCTION is the result the sequence of statements would produce
if they were applied to the actual parameters provided.
 
Clause 9.5.1: "A function is an algorithm which operates on parameters
and produces a single resultant value of a specific data type. An
invocation of a function in an expression evaluates
to the resultant value at the point of invocation."

As a consequence, a type-specification is "evaluated" once, *on
invocation of the function*, to determine the types of the actual
parameters and the types of the local variables.  The processing of
those declarations is conceptually simultaneous, but there may be
dependencies among the declarations, and those dependencies influence
the order in which the declarations must be "evaluated" in order to get
the proper interpretation.

Clause 9.5.4: 
"A local variable may appear in the initialization of another dependent
local variable. The declaration of dependent local variables shall be
acyclic.
 
NOTE 1 -- The requirement for acyclic local variable declarations is to
ensure that there is always a valid initialization, which does have to
be the order of declaration."

!!! The above text of the Note appears to be the result of applying
Technical Corrigendum 2 to ISO 10303-11:1994.  The intent of the
original text was that it does NOT have to be the order of declaration. 
I don't know whether this was an intentional technical change.  But the
requirement for the order of local declarations to be meaningful would
have to be part of the normative text and not a Note -- it cannot be
deduced from the normative text. !!!

> As an example, if the following appeared in some function, would
> hi_bound1 and hi_bound2 both be 4, or would they be 4 and 5 respectively?
> 
> ...
> LOCAL;
>  x : INTEGER := 4;
>  my_agg : SET [ 0 : x ] of INTEGER;
> END_LOCAL;
> ...
> hi_bound1 : INTEGER := HIBOUND (my_agg);
> x = 5;
> hi_bound2 : INTEGER := HIBOUND (my_agg);
> ...

They would both be "4".
But if in fact, some Express tool decided the first was 4 and the second
was 5, and another decided they were both 4, and still another produced
a warning to the effect that this FUNCTION is not well-defined, they
should all be conforming.  The old Algol-68 rule for syntactically
correct nonsense applies here: "The further elaboration of the function
is not defined by this standard."

IMHO, using an "initialized variable" to determine the value of a
parameter of the type of another variable is *never* appropriate.  What
is wanted for the purpose is a "local constant" (see 9.4) and not a
"local variable".  The initializer" of a local constant is evaluated at
invocation (according to the dependency rules) and retains its value
throughout a single interpretation of the FUNCTION.  (An assignment to a
local constant in the body of the function is invalid.)  Because it
didn't originally have CONSTANT declarations (and because we were too
lazy to write the correspondingly complicated expression rules after we
added them), Express permits the use of local variables to parametrize
types.  The best modeling practice is to use local constants, but it is
acceptable to use local variables that don't actually vary in the body
of the function.  But it is simply bad modeling practice to use a local
variable to parametrize a type AND change its value.  The result is a
meaningless model, whether or not some canonical interpretation can be
gleaned from the EXPRESS standard.  "Your results may vary."

-Ed

P.S. Local variables themselves are an artifact of the (inappropriate)
choice of a procedural model for the definition of a FUNCTION in
EXPRESS.  If an applicative model (like LISP or APL or mathematical
functions) had been used, EXPRESS would only have constants and actual
parameters.  And an applicative model has a naturally static
interpretation, which is correct for the purposes of EXPRESS.  (But I
lost that battle with the "Pascal heads" in 1989, who correctly observed
that the STEP modelers of the time would only be able to write
procedural functions! ;-)

-- 
Edward J. Barkmeyer                       Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260               FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."