On 19/01/17 06:00 PM, Peter wrote:
As the grammer for new_ordinal_type is new_ordinal_type: enumerated_type | subrange_type ; (a) would still be parsed as "new_ordinal_type". from that point, only one token, either ; or .. is needed to resolve which "new_ordinal_type" we have. Don't see the problem. Regards, Peter
Hello Peter,
Ahhh. Some light. If the parse is shift-reduce a-la bison, yes.
If the parse is recursive descent, it may be different story. The enumerated/subrange choice can not be delayed.
I am too green to know but I find it hard to believe that the type classification of a grammar ( LALR( 1 ), etc. ) depends on the parsing method.
I have chosen recursive descent. It is easier to understand and the error messages are more meaningful because the parser always knows where it is in the productions. The probability is higher that others ( who are not bison gurus and who want to stick with pascal source ) may take an interest in the compiler.
I have a circular buffers at both the lexical and token levels whose size can be set so the lookahead is not a problem.
Up until this point, I have not had a lookahead problem ( at least that I am aware of ) and it has been my intention to generate a phase 1 parser for an eventual compiler that used strictly lexical information.
However, I am now leaning towards the idea that using the semantic hints as provided by the multiple identifier types in the productions may be wiser. Type mismatches would be detected and reported much earlier at the expense of maintaining a symbol table stack and the parser would more closely follow the 20106 standard. Is this: true? wise?
Regards and thanks,
Paul