Re: [office-formula] Portable "documents"

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Rob, Patrick, all,

a few more comments are below, but my impression is that the portable
document issue can only be solved by looking at the various places where
the term "portable" is used individually. So, what about the following
approach:

1. In a first pass the specification is adapted to make use of the new
performance targets the SC has agreed. Essentially this means that terms
like "document" are replaced with "expressions" and terms like
"implementation" and "program" are replaced with "evaluator". This may 
require small adaptations of the language (in particular if must is 
replaced by shall, etc. at the same time), but should not change the 
constrains themselves.

2. In a 2nd pass, or in parallel, the portable document statements are
turned into notes, but without rephrasing them or moving them.

3. In a third pass, the notes are checked individually. If they can be
turned into statements what is implementation or undefined behavior of
evaluators, they are rephrased accordingly. If they can be turned into
statements what is optional behavior of an evaluator, the are also
rephrased accordingly. And if both is not possible, they are kept as is.


Some more comments are inline.


On 12/15/09 22:38, robert_weir@us.ibm.com wrote:
> Patrick Durusau <patrick@durusau.net> wrote on 12/15/2009 08:59:27 AM:
> 
> For example, instead of saying "Portable programs shall not dereference a 
> null pointer", we would say "The value of a dereferenced null pointer is 
> undefined".  Or instead of saying "A portable program shall not depend on 
> the size of an integer" we would say "The size of an integer is 
> implementation-defined".  So, the concept of a portable program was not 
> explicitly stated, although in practice it could be derived:
> 
> 1) Avoid all undefined behaviors
> 2) Do not depend on any implementation-defined or implementation-dependent 
> behaviors

I think it is important that we always state here if we are talking
about expressions or evaluators. The size of an integer is actually a
property of an evaluator, and dereferencing the a pointer is an
operation of an evaluator. So, what we are talking about here are
behaviors of evaluators.

In contrast, we talk about expression if we say undefined and 
implementation defined behavior should be avoided. If one does so, on 
gets a portable document.  So, what we may say is that there is a set of 
implementation defined, undefined and optional behaviors for evaluators, 
and that one gets portable expressions by not relying on these behaviors.

> 
> I wonder if an approach like that might result in a tighter specification? 
>  In other words, rephrase all portability constraints as positive 
> statements about undefined, implementation-defined and 
> implementation-dependent behaviors?

This goes into the same direction as I have suggested a few days ago.
So, yes, this may be a reasonable approach, except that I think there
are more options to rephrase statements about portable document than
turning them into statements what is undefined, implementation defined
or implementation dependent. Another option is to declare behavior to be
optional. For instance, while the size of an integer is undefined, there
may be a minimum size that all evaluators shall support. But evaluators
may support larger integer values. If they do so, the result is well
defined. Only only does not know whether larger values are supported.

So, if we say that the size of an integer value us undefined, there is 
no information what integer size is supported by all applications.

If we specify the minimum integer size, and declare the use of larger 
integer sizes to be optional, document authors know the minimum integer 
size that is supported, and they also know that if larger sizes are 
supported, the result of the formulas is well-defined. That's much more 
than in the first case.

Michael
> 
> 
> -Rob
> 
> ---------------------------------------------------------------------
> 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 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering