I agree with nearly everything you said except for I'm not ready to make a conclusion, but then again you're a bit further along then me. Continue with your approach. I think its the most promising. If it turns out that we need to alter course, as you said that would be simple.
My only real concern is not ending up with a HUGE monolithic class for finding all 100 ptgs and the variants! I've not taken a close look at your stuff yet (only scanned it) but if you're approach keeps that in mind then I'll be happy. I would like to SEE the other approach. Basically I want us to pick the best approach. But any approach must be: * maintainable * read * write * not preclude an evaluator Or it will be insufficient for our requirements for 2.0. Take a look at the vision doc and see if maybe you can add/modify it based on your formulotic expertise. -Andy Avik Sengupta wrote: >After showing some code, i think i am now entitled to express some >opinions :) .. so here goes some thoughts for whatever it is worth. > >I had looked at using a parser generator approach to parsing formula's (i >specifically looked at antlr, not javacc ..) , especially since someone >mentioned (on this list, i think) that that was how Gnumeric did it. However, >at the moment i think its overkill. > >The code in FormulaParser.java is a relatively efficient recursive descent >parser. While its handcoded (as against generated thru a parser generator), its >pretty small, and so i think the maintainence will not be a much more expensive >option than maintaining a javacc grammer. Also, while it is not functionally >complete, i think i know how to extend it .. its got a pretty simple structure >with easy mappings to the actual grammer, so if u look at it, it should be >apparent. It might get a little more inefficient when we do cell ranges ( i >havent figured out a simple way to tell a range using one lookahead character, >tho i think there might be a solution). > >Most important, it would be simple to replace the current handcoded parser with >a generated one pretty trivially (we just need to move out some static/factory >methods from there, and then replace the whole class). > >Which brings me to my next point. I think the tokenising should be done in one >place, rather than distributed accross different ptgs. Andy, while i get your >point about over 100 ptgs, i think that the grammer for a formula is much >simpler. We do need to take care of the multiplicity of Ptgs by using some kind >of factory to create the actual ptg instances, but the kind of tokens we need >to recognise are limited (For example, there are many many functions, but from >the tokenising point of view, its just one kind of token, ie fuction := ><functionName> ( [<arguments>] ) >arguments := <expression> [, <expression>]* > >So the general idea is we tokenise a function name in one go, but then pass the >actual function name to some factory to get the actual ptg. > >Some of the above is half baked, but i hope there is some logic to why i think >tokenising a string inside a ptg is a bad idea. > >So, the next thing on my list is one to get cell references, and second to wire >the whole thing up so that i can start to write simple formulas. i'll do one of >the two over the next two days, depending on my mood :). To do either i'll need >some help from the hssf experts, so expect some dumb question on the list :) > >Regards >- >Avik > > >Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > >>I hope to work on this later today. Scanning it, it looks really good! >> Far better than my messing around for sure. This shows the most >>promise of anything I've seen yet. >> >>I'd like to see the javacc aproach as well but I remain unconvinced that >>it will adequately work both directions. I'd rather be able to >>read/write/modify only a small subset of the formulas in Excel then be >>able to read all of the formulas. Obviously for 2.0 the goal is all >>non-obsolecent formula pieces. I'd still like to see a prototype of >>that. (and any other approaches someone may have). I think we're well >>on our way to finding the best approach and I think excellent formula >>support will fall out from there. >> >>-Andy >> >>Avik Sengupta wrote: >> >>>This contains all that i have mailed to the list in the last few days, >>> >>diffed >> >>>against the latest cvs. >>> >>>this has the functionality to create a RPN ptg array from a string, and >>> >>back. >> >>>try java org.apache.poi.hssf.record.formula.FormulaParser <formula> >>> >>>after compiling and setting the classpath. >>> >>>I will now look at handling some basic cell references and also integrating >>> >>all >> >>>the stuff so that we get some level of access from usermodel. >>> >>> >
