RE: [office-formula] Expression Calculation - dropping returns?

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

 1. I think we should not be using "returns" in any case.  This should be
descriptive of what the result is or what the expression stands for, but
"returning" and "computing" are probably over-used in this specification.
We should use descriptive rather than procedural language wherever possible,
it seems to me.

 2. There are a number of difficulties with 2.2 Expression Calculation.
First, we need to distinguish between the lexical/syntactical constructs and
what they signify (the notional thing).  I am not sure we have that down
here.

 3. With 2.2(1), we are talking about syntactical structures for string
constants and numerical constants.  The result (what the form signifies)
should be the representable Number or Text, respectively.  (Note that the
constant might not be for a representable Number or Text, but that might not
be a syntactic matter but a limitation of the evaluator implementation.)
    [If this business is addressed in sections 3-5 where tied to specific
case, I agree it can be simpler here.  I don't think we can do without
Chapter 2, but it should be simplifiable.] 

 4. I don't think the observation about display in 2.2(2) has any
significance here.  OpenFormula formulas (and their constituent expressions)
don't signify the provision of displays, nor determine how the presentation
for display is controlled.  OpenFormula formulas signify notional things
like derived Number, Text, etc., values (including arrays in some cases).
These notional entities may be parked in (notional) table cells and other
places.  How those notional values are presented (and entered) via an
interactive application, and how they are persisted to and restored from
text in elements and attributes of a document format are to be appreciated,
but they are separate matters.  We probably have to clarify that separation
though, so it is clear what the settings/contexts in a hosted document
format are responsible for.

5. Returning to the first paragraph, we talk about recalculation when,
arguably, we don't say much about what recalculation is and when it might or
might not happen.  
  5.1 I think it is more apt to talk about what the formula determines any
time it is to be determined (although calculation can of course be avoided
when it is evident that the result cannot change unless the formula itself
is changed).  
  5.2 I would say something like "the value signified by a formula is
determined from the values dertermined by the top-level operations and
function references applied to the values determined by their constituent
operands and function parameters."  
  5.3 If a good syntax were available, we could show how this determination
of the value follows the syntactic construction of the formula.  (It might
be useful to have this section *follow* the current section 4, unless
sections 3-4 continue the description of how values are determined.
  5.4 The use of "eager" (as usually contrasted with "lazy") in 2.2(3a) is
not a good idea.  All OpenFormula evaluations are potentially lazy in the
sense that as soon as there is an error condition, the evaluation of any
other terms needed by an embracing operation can stop.  I'd be surprised if
SUM(...) evaluated its entire list of operands before starting the
calculation.  (I'd not be surprised if an implementation did attempt to
evaluate all of them first, either.) 
  5.5 It is the case that some functions only evaluate operands that are
needed to determine the result.  IF(cond,thenval,elseval) and CHOOSE(...)
are good examples.  We can call these special non-functional forms or we can
talk about a system of evaluation where every function determines how and
when (which of) its parameter values must be established.  I am not sure
which is the preferable case, and which approach allows us to have the
fewest exceptions that need to be described.

There is more to be done here and elsewhere in keeping the layers of
concepts separated and clear.  

It is important to clean up the rest of 2.2.

 - Dennis
 

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Saturday, January 23, 2010 07:26
To: office-formula@lists.oasis-open.org
Subject: [office-formula] Expression Calculation - dropping returns?

Greetings!

In current Expression Calculation, propose to drop:

>   1.
>
>       If an expression is a constant number or string, that constant
>       is returned
>
>   2.
>
>       If it is a reference, the reference is returned. If a reference
>       is to be displayed, the /value of the reference /is displayed,
>       not the reference itself.
>
What an expression or reference returns should be defined by its 
definition. Yes?

Why repeat that here?

Should only have rules, such as order of evaluation, which are *not* 
defined elsewhere here.

Hope everyone is having a great weekend!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php