On Tue, Aug 10, 2010 at 5:01 PM, Ben Karel <eschew at gmail.com> wrote:
> I am struck that this implies a significant intertwining of state between
>> the parser and the lexer. In particular, if the Lexer is to correctly report
>> operator precedence to the parser, it needs the ability to look up the "<<"
>> operator in the appropriate lexical environment. This *seems* to imply
>> that symbol resolution is inextricably interleaved with parsing.
>>> Doesn't option two amount to operator precedence parsing, more or less? If
> you go that route, the lexer should not need to worry about precedence
> information. Seems like a much better solution to me.
>
I don't think so. The issue here is that the precedence is dynamic, and most
parsers aren't equipped to deal with that at all. The workaround is to
introduce distinct tokens for operators at each supported precedence and
have the tokenizer/lexer return the appropriate one.
shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100811/ce784aaf/attachment.html