-----Original Message-----
Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> Actually I don't think you can define a grammar where two operators have
> the same precedence but different associativity. Be it a pure BNF
> grammar, or a classical yacc specification (using the %left and %right
> declarations).
You are correct in stating that in a classical yacc specification, you can't
declare two operators to have the same precedence but different
associativity. But that's because syntactically you can't express the idea.
You'd have to do something like
%left PIPE_LEFT_OPERATOR
%right PIPE_RIGHT_OPERATOR
Or you could put them in the opposite order. But, syntactically, they do
have to be on different lines, and that makes them have different
precedence.
However, you could have the following productions in a yacc grammar:
exprB: exprA PIPE_LEFT_OPERATOR exprA
| exprA PIPE_RIGHT_OPERATOR exprA %PREC PIPE_LEFT_OPERATOR
;
(or something close to that -- it's been a while since I actually wrote yacc
grammars).
I assume that the generated parser would act in a manner similar to the way
it behaves when it catches you trying to chain together %nonassoc operators:
it generates a parse error.
And given the fact that (IMHO)
"hello, world" ~> print <~ STDERR;
is an abomination, a parse error would be just fine by me.
But cooler heads might just decree that the shift/reduce conflict is to be
resolved one way or another, so that
A ~> B~> C~> O <~ X <~ Y <~ Z
parses as either
(A ~>B ~> C ~> O) <~ (X <~ Y <~ Z)
or
(A ~>B) ~> C) <~ (O <~ X <~ Y <~ Z)
Neither is likely to be what you want, however. And given the level of
difficulty that most people have with precedence and associativity rules, I
think it reasonable to require the parens if you want to mix ~> and <~ like
that.
=thom
There are 10 kinds of people in the world:
those who understand binary, and those who don't.
