Re: [office-formula] Constraints and infix ^

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 01/21/2009 10:04:38 AM:
> 
> Rob,
> 
> robert_weir@us.ibm.com wrote:
> > "Implementation-defined" is not a term that we will see defined in ISO 

> > drafting guidelines.  We'll need to explicitly define it in our text 
what 
> > it means.  Certainly in other standards, like ISO C++ items that are 
> > implementation-defined can also have additional restrictions specified 
in 
> > the standard. 
> >
> > It is perfectly legitimate to say "implementation defined" and also 
> > specify additional restrictions.  For example, ISO C++ says that the 
> > length of a character is implementation-defined, but it must be at 
least 
> > 8-bits long.
> >
> > 
> Err, but doesn't that run afoul of your concerns for interoperability? 
> That is in the ISO C++ example there is a floor for representing 
> character of 8-bits but what happens if file was generated with an 
> application that supported a 16-bit definition is passed to an 
> application that only supports 8-bits?
> 
> Besides, if the formula group wants a defined set of results, then the 
> results aren't by any means "implementation defined," we are simply 
> offering a choice to implementations. They cannot chose, for example, 
> the weather report that David suggested.
> 
> Yes?
> 

Implementation-defined behaviors tend to stem from a few causes:

1) The behavior would cause performance problems if it was specified 
completely, i.e., implementations require the ability to optimize behavior 
to match their circumstances.  With programming languages, this was the 
core reason for implementation-defined behaviors.  Programs would execute 
faster if the data types matched the capabilities of the underlying 
hardware, and that hardware itself was not standardized.  Since the 
compilers came with the hardware, every vendor wanted their compiler to be 
optimized for their hardware.  It make interoperability more difficult, 
though practices arose called "portable coding" to somewhat ease the pain. 
 As programming languages evolved (in the presence of faster and faster 
hardware) we started to see new languages, like Java, that did not leave 
as many items to be implementation-defined, and therefore were more 
portable.  But even then some behaviors like multi-threading, are so 
machine-dependent that even Java cannot specify its constraints 
completely.

2) The "need" for product differentiation.  In practice this happens more 
than most people realize.  Vendors want a standard to placate customers, 
but don't want the technology standardized so much that the underlying 
products become substitutable low-margin commodities.

3) A standard created from divergent practice.  Some standards are created 
from nothing.  Those are the easy ones.  Harder is when you already have a 
number of divergent applications with different behaviors and try to 
standardize them.  C++ was a good example.  There were already a number of 
C++ compilers, based on Bell Labs original work, before the ISO standard 
was created.  Each vendor added their own extensions, at the syntax level, 
and these were not compatible.  The challenge of standardization was to 
forge a way forward. Do you accept every vendor extension or difference? 
Do you make areas of disagreement "implementation-defined"?  Do you force 
all vendors to conform to a single way of doing things?  Obviously, 
interoperability going forward suggests the latter.  But that only works 
if the vendors see the light that the present pain of changing their 
implementation to conform to an interoperable standard is minor compared 
to the benefits of having a piece of a growing market when the underlying 
technology takes off.

I think spreadsheet formulas are mainly divergent because of #3, though 
there may be some #1 performance-related issues at stake as well.  Getting 
over #3 is optimal, I believe, but it would require a consensus among 
implementors that I'm not sure we have at this point.  We only have 
carrots here.  We have no sticks.  We need to find the art of the 
possible.

-Rob