Re: User defined precedence for user defined operators.

glen herrmannsfeldt wrote:
> Brooks Moses wrote:
>
> > Richard E Maine wrote:
>
> >> 2. It might even be possible to have ambiguities because changing
> >> precedence can change what the operands are. I haven't tried to concoct
> >> an example, but I suspect it could happen.
>
> I was going to write something about this, but instead I am
> cross-posting to comp.compilers, where the people who actually
> know about parsing theory reside.
>
> For new readers to this discussion, the question relates to being
> able to specify the precedence for user defined operators (operator
> overloading), and the possible ambiguities that can cause.
>
> As far as I know, the languages that allow operator overloading
> use the same precedence in all cases for each operator.
>
> In any case, it is convenient to parse reading left to right,
> and to be able to make decisions with only a small amount
> of reading ahead.
>
> > Trivially:
>
> > Type(a) + Type(b) returns a Type(b)
> > Type(b) + Type(a) returns a Type(a)
>
> > Type(a) * Type(a) is lower precedence than cross-type +
> > Type(b) * Type(b) is higher precedence than cross-type +
>
> > Type(b) + Type(a) * Type(a) + Type(b) is (arguably) ambiguous.
>
> -- glen
>
> [I don't think I've ever seen a language where the operator precedence
> depended on the types of the operands, and I hope I never do. -John]


    This reminds me of Prolog, where the user can define new operators,
their type (prefix, suffix, rl, lr) and preference, all this at
runtime. In that language you needed to transform a list of objects to
a tree - a simple one-pass hand-written parser.


    Your case is much simpler - you can define your yacc syntax with any
precedences you like. BTW, don't forget to define a special expression
type for '( expr )'. After parsing an expression, just traverse the
(wrong) expression tree and do the needed rotations and type inference.


    I don't see ambiguity in your example. If your operators are
left-to-right ones, then
Type(a)+Type(b)*Type(a) is (Type(a)+Type(b))*Type(a), i.e.
Type(a)*Type(a), and then the whole expression is
Type(a)*Type(a)+Type(b), i.e. Type(a)*(Type(a)+Type(b)), i.e.
Type(a)*Type(b).


    The right-to-left inference can be different, but you can define in
your syntax that the parser (type and preference inference) goes from
left to right and bottom up. This will work even for different groups
of rl and lr operators if their precedences do not interleave. For
example, you can have a group of lr ops with preferences in the range
of [80,100], rl ops with preferences in the range of [50,70], and lr
ops with preferences in [20,40].


    In addition to what our moderator said, do you think the user of your
language can be confused by these floating preferences? I always
thought that a language has to be easily writable and in most cases
readable!-)


    Michael

Return to the comp.compilers page.
Search the comp.compilers archives again.