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] Let's make "^" left-associative, not right-associative

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 07/15/2006 09:51:15 AM:

> In nearly all spreadsheet applications, ^ is left-associative, including
> Excel, OpenOffice.org, Lotus 1-2-3v9.8, and Corel Quattro Pro.
> That means 2^3^2 is all those cases is 64, not 512.
> Gnumeric 1.4.3 is an exception, it's right-associative.  Don't know
> about KOffice.
> Therefore, I believe we should change "^" to be left-associative
> for the file exchange format, NOT right-associative. Right-associative
> is slightly more conventional in the non-spreadsheet world, but
> not strongly so, and clearly left-associative is by FAR the most common
> convention in the spreadsheet world.  Also, very
> few people really want to DEPEND on having "^"
> be right-to-left (they'd insert parens in the rare case where
> they use it) -- and by having all binary operators left-associative,
> we simplify implementation for those who hand-craft their parser.


> As usual, this is only for the interchange format;
> if an application (like Gnumeric) wants
> its UI "^" to be right-associative, that's fine.  But I expect most
> spreadsheet applications will follow the conventions of the
> exchange format, so I think the associativity rules should follow
> the more common case.

I'm a little wary of the phrase "only for the exchange format".  This will only work if the UI format has an unambiguous one-to-one mapping to the exchange format.  This would need to be birectional, otherwise chaos ensues.  For example, suppose one format decides to have an AND() that short-circuits, and to support that case we create a new AND_SHORT().  So, in that editor, the user types AND() and the stored formula has AND_SHORT().  When the user loads that spreadsheet, what happens?  I think they would be somewhat annoyed to see their formula's text change after simply saving and re-loading, so the editor would need to be able to map the formula back to using AND().  But then what happens when the document is sent to another user on another spreadsheet editor, one that does "normal" AND()by default?  Will it show up then in the formula bar as AND_SHORT()?  If so, what will the colleague using that spreadsheet editor think of this new function which they have never need before?  Will their editor support it?  Will it be documented in their help system so they can understand what it does?  

I think we need to stick to the premise that the formula that appears in the formula bar should not change as the file is saved, loaded or exchanged among editors, unless the user changes it, short of removing ignorable whitespace, and normalizing case of function names.  Although our formula spec does not need to specify this, I think we're asking for trouble if we specify it any way that makes that simple preservation of the end-user formulas difficult or impossible to implement.

I guess I just haven't bought into the logic of forcing all compliant ODF editors to support a new function so a single implementation can avoid lining up with the others.  Maybe someone can better explain this to me.  I've said this before, if we end up with the same number of distinct families of spreadsheet formula languages as we have implementations, via function levels, levels within functions, processing directives (e.g., _DISTINCT_LOGICAL and _AUTO_TEXT_TO_NUMBER), or other means, then we will have failed to accomplish the purpose of standardizing, at least in my opinion.   If we find a specific approach used by one implementation that is clearly better, then let's all do it.  If we find a way that clearly worse, then let's none of us do it.  And if all is equal, then make a choice.  I think we done the first two quite well.  But we're sometimes having a hard time making a choice between equally good alternatives.    


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