[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Portable "documents"
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, firstname.lastname@example.org wrote: > Patrick Durusau <email@example.com> 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 firstname.lastname@example.org 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