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