[bitc-dev] Quick haskell question

[Ben Karel]

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
algorithm.

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
>>> 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
>
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100811/bfa22c6d/attachment.html