Re: [office-formula] Grammar

[Eike Rathke <erack@sun.com>]

Hi David,

On Fri, Mar 03, 2006 at 15:00:09 -0500, David A. Wheeler wrote:

> The grammar Eike posted is happily very similar (yay!), but I think
> it is also overly complex, e.g.,
> data type mismatches are best handled by typing, not the syntax.

Ok. We can keep the syntax quite simple then, but will probably have to
elaborate a bit more on parameter typing for specific functions, which
is also fine.

> We can also handle whitespace separately, and not try to
> create a large independent set of syntax for references.

Most of my whitespace approach resulted from the fact that whitespace is
significant in the sense of that it should be preserved, because that is
what the user expects. If we declare that somewhere and make it part of
the spec then I'm fine with it.


> One issue: neither really specifically identifies the NLF intersection
> operator.  However, "!" is the cell intersection operator for ranges
> in OpenFormula, e.g.:
>  [.A1:.G20]![.A1:.Z2]
> I don't see why NLF intersection needs a syntactically separate
> operator.  It's the same operation (intersection).

You need to be able to represent it different in the UI. If you have
a ColumnLabel, for example cell content "Sales", and RowLabels, say
"Hamburg" and "Capetown", you're able to write a formula

=Sales Hamburg

note the blank as an operator here. This works in OOoCalc even though
Calc normally uses '!' as the intersection operator, whereas using
a blank as an operator between two "normal" ranges does not work. These
labels are not defined NamedExpressions, they are looked up in the
current sheet if enabled under Tools.Options.Calc.Calculate, or can be
explicitly assigned under Insert.Names.Labels. When loading the document
again, the user expects to see the blank and not some other operator.

> One approach:
> if you have NLF, that means that you just predefine the relevant
> "NameExpression"s from row and column labels, if you actually
> want to use NLF... then when you
> use a named expression, it "just works", e.g.:
>   Summer ! Sales
> Hate that? Another approach would be to use string names, e.g.,
> intersection just happens to
> accept two different types: string names and cell references, like this:
>  "Summer" ! "Total Sales"
> I like the NamedExpression approach better, though.
> In my mind, that's just an option on the spreadsheet that has the
> side-effect of automatically maintaining a set of NamedExpressions
> based on the labels of the top row and left column.
> Is there a reason that wouldn't work?

Automatically looked up labels, at least in OOoCalc, have a different
definition from NamedExpressions regarding what cell range they
encompass. A label always names exactly one column or row, not more. If
used in =SUM(ColumnLabel) the range expands as soon as a value is added
to the column at the bottom of the other values, it stops as soon as an
empty cell is encountered.


> The "second =" marker is an interesting approach.
> It appears to be the "opposite" approach of
> having a set of volatile functions,
> and in fact the two approaches should complement
> each other nicely.  I guess I don't fundamentally
> object to it, if it seems useful, though it's clearly
> only for very advanced users.
> I'm not sure how exactly to specify its semantics, though.

The formula is recalculated whenever one of the predecessors it depends
on changed, regardless whether the result of this formula is needed by
the view to display, or accessed from any other spreadsheet formula.

Put that in nice English wording ;)


> >Yes. In fact the cell "union" is not a union, but a list instead. A union 
> >would unify overlapping ranges, the list does not. (A1:A3;A2) evaluates A2 
> >twice.
> 
> Yes, I even noted that in the OpenFormula text.  I don't like the term 
> "union", it's very misleading, but that seems to be what people call it.

I also call it union in informal speech, but for the spec we should call
it list instead.

> I originally called it "reference concatenation" but no one knew what that 
> meant...!  The problem with "list" is that there are many other kinds of 
> lists.  Any other names?

IMHO 'ReferenceList' would be unambiguous, that names exactly what it
is, a list of references.


> I don't think we need to support more built-in types for constants in the 
> SYNTAX (except _maybe_ complex numbers).  Most types should derivable from 
> Number, String, and logical values, when sent through functions.

Do we even need Logical? Yes, I know there are implementations that
unnecessarily differentiate between Number and Logical, but so far
I don't see any benefit in defining a built-in type for it.

  Eike