[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Grammar
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]