From: Tim J. <te...@me...> - 2000-09-20 01:33:29
|
I'm not really sure what you mean by "look behind". In CobolForGCC we are using bison which is an LALR(1) look ahead compiler. It needs considerable help to parse COBOL, due to the fact that COBOL is not LALR(1). You can see the results at http://CobolForGCC.sourceforge.net (browse the CVS source into the gcc/cobol directory; there is a discussion of the help the parser needs in the file cobctok.def). We have the grammar for the COBOL85 nucleus done - the other parts of COBOL do not present any unique problems. There was a long discussion about parsing COBOL under the GNU COBOL project at http://www.lusars.net/maillists/gnu-cobol/threads.html. Do a find on "pars" or "yacc". Learn from our mistakes. I looked at numerous techniques for parsing COBOL. The hacks needed to make BISON/YACC work are only a few hundred lines of code, so I gave away notions of backtracking compilers etc, for reasons which are explained in the mailing list discussion. Basically backtracking makes creating reasonable error messages very difficult. As the GNAT (ADA) compiler crew showed, you can write a fast parser with good error messages by hand as long as writing several hundred thousand lines of extra code does not bother you. But really parsing is a miniscule fraction of building a COBOL compiler. Code generation and optimisation and the runtime libraries are a much larger task. Tim Josling Fishfan1 wrote: > > Hi > > I am in the process of developing lexical and syntax parsers for COBOL. I > have thus far taken a 'look behind' (vs. 'look ahead') approach. I have > heard that the 'look ahead' approach is significantly more effective from a > performance point of view but would still like to know if anyone knows or > has proven that the 'look behind' approach will not work (forgetting about > performance). > > Also, I would be interested in communicating with anyone who has interests > or experience in developing COBOL parsers and/or compilers. > > Best Wishes > > Fish |