Re: 10206 lexical ambiguity

Paul Isaacs <[email protected]> Thu, 19 Jan 2017 20:22:10 -0500
Newsgroups gmane.comp.compilers.gpc
Message-ID <[email protected]>

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


_______________________________________________
Gpc mailing list
[email protected]
https://www.g-n-u.de/mailman/listinfo/gpc