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

["David A. Wheeler" <dwheeler@dwheeler.com>]

robert_weir said:
> > As usual, this is only for the interchange format;
> > if an application (like Gnumeric) wants
> > its UI "^" to be right-associative, that's fine. ...
> 
> 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?

To be fair, this is what spreadsheet applications typically
do now with foreign languages.   In many applications, if you set the
language to French, you'll see the _French_ names of the functions,
not the English ones.

Anyway, the case as you describe won't happen.  Any one application
better have a consistent mapping, and in practice, in English it'll generally
be one-to-one.  But let's go with your example.  In my app, my "AND"
maps to OF "AND_SHORT".  Thus, my app will have another function, e.g.,
"AND_NOSHORT".  I load in your sheet, and see lots of AND_NOSHORTs,
write it back, and you see "AND" as usual.

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

Actually, the spec says you SHOULD preserve whitespace, because people
insert whitespace for readability, and we don't want to lose that.
All implementations I know of do this.

The format isn't exactly identical to the UI in a few cases:
[] around cell names (which ensure that cell names are unambiguous and
allow very wide sheets), and ";" is not the function separator in all UIs.
No actual humans will have trouble with this.

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

Now there I completely agree.  To my knowledge we're completely fine.
Let me know if you can find an exception.

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

Huh?  Don't think we're doing that.

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

That is merely a proposal on the table.

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

Fair enough. That is actually true for any standards body which
is not a farce.  If there's really only one person who makes all the decisions,
and everyone else is there to pretend, then there are often
no discussions, no debates.  There are definitely discussions
and debates here :-).

--- David A. Wheeler