Re: [office-formula] Grammar

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

Okay, I'm trying to combine Eike's grammar, the OpenFormula grammar,
and other comments (dropping "levels") into one super-de-duper grammar.

I'll post my hopefully-an-improvement results later, but while I'm
doing this I thought I'd make a few points that are debatable, but
I think my first cut approach is at least defensible:
1. I think the syntax has to PERMIT empty parameters, because
    we have spreadsheet implementations where this is critical
    (and we want to be ABLE to read them).  In the ambiguous case
    of "zero parameters, or one empty parameter", presume zero.
    E.G., these should be legal syntactically:
      DUMMY()        0 parameters
      DUMMY(1;)      2 parameters, 2nd one empty
      DUMMY(;;)      3 parameters, all empty
   Yes, Excel and Gnumeric both do this.  I suppose we could
   say specific IMPLEMENTATIONS might not support empty parameters,
   but it'll be a problem if the syntax can't even express them.
2. Historically cell concatenation has been notated with the
    function separator (comma or semicolon).  This can be
    disambiguated by a GRAMMAR, but it's REALLY dangerous... one
    small slip, and everything is screwed up.   It also makes
    the grammar much more complicated than necessary.  OpenFormula
    instead used "~" as the cell concatenation ("cell union" or
    "cell list") operator.... this makes the grammar MUCH simpler,
    because now you can treat "~" and "!" (intersection) as
    just two more operators.  If functions return references, you
    can use "~" or "!" or ":" on them without any weirdness.
    You can DISPLAY it using the function separator if you want to.
3. Rathke's grammar gets really complicated when it deals
    with referencelists, etc.  The problem is that it forbids
    some constructs that would make sense (e.g., you can't have
    cell concatenation outside a function call, even if you want
    to send the results to an operator).  I think it's better to
    have a simple grammar with a few operators, and if an operator
    isn't happy with a datatype, let the OPERATOR say so.  You're
    more likely to get consistent results that way, because it's simpler.
4. Cell column letters MUST be uppercase; I believe the
    OpenDocument spec specifically requires it.  And there's no reason
    to be flexible about this. By being picky about that, we're much
    more likely to be able to write back out exactly what went in
    (which is handy when you're doing diffs).

--- David A. Wheeler