[bitc-dev] Quick haskell question
eschew at gmail.com
Wed Aug 11 17:19:02 PDT 2010
Right, which is why you don't have the *generated* parser handle operator
precedence -- you implement the shunting yard algorithm (or whatever) as a
post-processing pass, like Mark P. Jones described. During conversion from
parse tree to AST, rather than token stream to parse tree. Conveniently, the
type (Expr, [(Op, Expr)]) is the type of input to the shunting yard
Doing operator precedence parsing with the shunting yard algorithm makes it
particularly easy and natural to use a map from (op, op) ->
shunting_yard_decision rather than a map from op -> precedence_level, and
the shunting yard algorithm should also (I think) generalize nicely to
mixfix, if you end up going there.
I don't quite see the problem with function application -- it can be treated
as just another binary operator if you wished to have its effective
precedence in between other operators.
On Wed, Aug 11, 2010 at 7:56 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
> 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
>> 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.
> bitc-dev mailing list
> bitc-dev at coyotos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev