Re: [office-formula] Grammar

[Eike Rathke <erack@sun.com>]

Hi David,

On Sat, Mar 11, 2006 at 18:24:06 -0500, David A. Wheeler wrote:

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

Seconded. However, we'll have to define for each function what an empty
parameter at that position actually means.

> 2. Historically cell concatenation has been notated with the
>    function separator (comma or semicolon).

Actually, what implementations use in the UI, is that separator _and_
the entire list enclosed in parentheses, e.g. =SUM((range1;range2)) is
_one_ ReferenceList argument to the SUM function.

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

I second that using some distinct operator in the file format would be
easier to parse and less error prone. However, applications probably
will still have to implement parsing the (...;...) notation for UI
purposes because that's what people are used to, leading to duplicated
effort. Just as a thought..

Personally I'd prefer using an operator even in the UI, _because_ it is
less error prone.

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

Is a ReferenceList anywhere used in that context? Anyway, being open to
that possibility, even if not used nowadays, is actually a good thing.

> 4. Cell column letters MUST be uppercase;

Why? I don't see any other advantage in that except when doing diffs
like you mentioned below.

> I believe the OpenDocument spec specifically requires it.

I didn't find anything that explicitly says so. Only the examples are
kept in uppercase.

>    And there's no reason to be flexible about this.

There's no reason to not being flexible about this. The entire
spreadsheet formula language is case insensitive.

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

Which for archive purposes sounds like a valid argument, but a diff
relying on the XML stream being identical after a write back is.. well..
maybe not appropriate. If we start being picky on this, there's a SHOULD
write uppercase column names and function names, and MUST be able to
read case insensitive.

  Eike