question regarding bound specs

[Ed Barkmeyer]

All,

I want to make it very clear here that what I said and what David 
Price said are not at odds.  David is 100% correct when he says:

> I'd take a look at Part 22 and the SDAI dictionary. There you find a concept
> where bounds are indeed evaluated at run time. For example, a bound can
> contain a query which can only be evaluated at run time. This applies to
> more than just aggregate bounds also.

This is because Part 22 defines the behavior of a particular kind of
*implementation*!  In particular, Part 22 defines a runtime environment,
a set of procedure invocations in that environment, and the required
behaviors of those procedures relative to the specifications in the
EXPRESS model.  The concepts of "compile time" and "run time" are 
meaningful for Part 22, and the procedural interpretation of EXPRESS
FUNCTIONs is part of the Part 22 specification for the runtime behavior.

EXPRESS itself, Part 11, does *not* define a runtime environment.
In EXPRESS, the definition of a FUNCTION is the effect the algorithm
would produce, using the EXPRESS computational model, whether it is 
implemented or not.  Part 22 defines the effect of a function as the
execution of the EXPRESS statements using the computational model of
the programming language and the mapping provided by Part 2x.  While 
an attempt is made to render the intent of the EXPRESS model as
accurately as possible into the programming language, those 
computational models are *not* identical, and some of the Part 22
results will not necessarily be identical to the EXPRESS interpretation.

It is entirely possible that the rendering of Liam's model into C++
via Part 23, for example, will cause the second call to HIBOUND to
return 5.  (I don't know that it does.)  In any case, the result of
that call is an artifact of the Part 23 mapping and the computational 
semantics of C++.    

In the same way, it is unlikely that Part 2x implementations will
produce the "correct" results for some of the strange operation
overload cases that can arise from the TC2 change to EXPRESS that
allows A + B where A and B are both instances of SELECT types.
And floating-point approximation is well-known to produce anomalous
results for WHERE clauses that test for equality between REAL values.

In sum, the effect of the Part 22 mapping is *not* the definition
of the EXPRESS construct.  It will usually be consistent, but not
always, particularly in "outlying cases".

-Ed

"The problem with having 'statements' in EXPRESS is that encourages
 people to write FORTRAN into models."
  -- Peter Wilson

-- 
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."