[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Spec tweaks
robert_weir: > General question -- has anyone done a formal analysis of our expression > language? I created a flex/yacc model of an older version of the grammar, and I did a hand-analysis of the current one. That's when I discovered that unquoted sheet names are fine for the usual case, but if you have subtables that are sheet names, you need to quote them. > Especially with recent tweaks and extensions, it would be great > to throw this all into LEX/YAAC (or whatever tool is used for this these > days) and confirm that we're not getting conflicts. I agree, that'd be a great thing. If anyone wants to do that, feel free to yacc/lex stuff at: http://www.dwheeler.com/openformula (MIT license, do what you want to with it.) I might do that if I don't hear from someone else soon. Also, before we set the spec in stone I want to hear from implementors who've already worked to implment it, anyway. > Also, did we have any explicit target for the complexity of grammar we > wanted, whether LALR, LR(k), GLR, or whatever? Sure, "must be implementable by a Turing machine". Not NP-Hard is a bonus :-). Ok, seriously... We didn't really state a particular complexity goal, but in practice I've tried to keep this to 1-symbol lookahead. E.G.: * If you see an Identifier, the next char is either '(' and we have a function, or not and we have a named expression. * In several cases '...' can mean more than one thing... but the NEXT non-whitespace character always disambiguates. In some cases, just seeing one character is enough to tell you what's next - that's particularly true for cell references, which are heavily used. --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]