Re: [office-formula] Let's make "^" left-associative, not right-associative

[robert_weir@us.ibm.com]

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

+1

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


-Rob