OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] Constraints and infix ^

"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.


"David A. Wheeler" <dwheeler@dwheeler.com>
Patrick Durusau <patrick@durusau.net>
robert_weir@us.ibm.com, office-formula@lists.oasis-open.org
01/20/2009 10:06 PM
Re: [office-formula] Constraints and infix ^

Patrick Durusau wrote:
> Err, if we say "implementation defined" isn't there a full stop at the 
> end of that sentence?

No.  Why would that be so?

> Otherwise, we are contradicting ourselves by then proceeding to define 
> Yes?

No, I don't think so.

"Implementation-defined" means that the implementation is free to
pick from a set of possibilities, as long as that selection meets the 
other requirements of the spec.  If the spec limits the set of 
permissible returns, then it must be one of those possible returns.

> I really think Rob has the better position to just say "implementation 
> defined" and then to let it alone.

That may very well be true!  In which case, let's argue about whether 
it's better to say "implementation defined, anything at all allowed" or 
"implementation defined, but must be one of the following {list here}".

Where _possible_, I believe we should try to gain agreement on semantics 
to the extent we can.  Particularly for such a basic operator as "^". 
In the case of 0^0, I think there are only 3 plausible responses: 1, an 
Error, or 0.  I think we can agree that "" is NOT acceptable, yet if we 
leave it "implementation-defined" without further limitation, then "" is 
a permissible result.

There are many reasons to try to _limit_ the amount variation in an 
"implementation-defined" result, if we can.  For example, it's much 
easier to create portable spreadsheets if we know that only one of a few 
possibilities can occur.  If 0^0 could produce a text value containing a 
weather forecast, it'll be harder to create portable spreadsheets :-).

--- David A. Wheeler

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]