Re: [office-formula] Implementation-defined, Unspecified, and Undefinedbehaviorsin OpenFormula

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 06/12/2009 11:43:47 
AM:

> 
> As you can tell by the attached spreadsheet, it turns out that there are 

> actually very FEW causes for something to be undefined in OpenFormula. 
> A few items that were SPECIFICALLY agreed to be undefined end up causing 

> "undefined" in several places in the spec.  So, I named those reasons, 
> which end up getting reused all over. See the attached spreadsheet for 
> details; they are:
> * DISTINCT_LOGICAL_TYPE
> * AUTO_CONVERT_TEXT_TO_NUMBER
> * ZERO_PARAMETERS_IN_LIST
> * OLD_BASE_CONVERTERS.  Basically, we want people to avoid these older 
> functions in the future... we specify just enough so that they can 
> continue to be used in older sheets.
> * PERMIT_EXTENSIONS.  A desire to permit extensions in certain very 
> limited areas, without requiring universal support.
> 


Would it be worth taking a declarative approach on some of these?  In 
other words, if it is too expensive to converge application behavior, then 
require it to be declared at the document level, as a mode, along the 
lines of what we do with date origins.

That way an implementation, if it chooses to, can adapt to the different 
conventions, or at the very least, warn the user if it encounters a 
document that makes use of (not just declares) a convention that it does 
not implement. 

-Rob