Re: How to change default outcome of shift/reduce conflict?

[Hans Aberg]

At 16:35 -0500 2002/01/15, Anthony DeRobertis wrote:
>Someone has put together a BNF grammar which I'm not sure is
>legal (at quick glance, it is ambiguous), but even if it weren't
>I'm not sure of its copyright status and seriously doubt the
>translation to LALR(1) would be trivial:

>>> answer_statement: ANSWER expr answer_btn_list
>>>                 ...
>>
>>> answer_btn_list: WITH answer_btn_list_oneplus
>>>              | /* empty */
>>
>>> answer_btn_list_oneplus: answer_btn_list_oneplus OR expr
>>>                      | expr %prec PSEUDO_MAX
>>
>>> expr contains a lot of things, expr OR expr is one of them.
>>
>> This is what looks wrong to me: That both
>> answer_btn_list_oneplus and expr
>> contains OR.
>
>Yes, that's correct. They have to -- it means two different
>things. Compare it to calling a C function where you can
>certainly do:
>
>answer(a || b, c, d || e).
>
>In HyperTalk "||" becomes "or". Unfortunately, in the case of
>answer's button list, "," also becomes "or". So:
>
>answer ... with (a or b) or c or (d or e)

I think that rather than fiddling around with operator precedence, you need
to figure out the correct semantics in relation with the grammar. Compare
with the grammar
        http://www.jaedworks.com/hypercard/scripts/hypertalk-bnf.html

Assuming that you want that the "or" of
  answer ... with x_1 or ... or x_n
be treated as a ",", and when using parenthesizes around an expression, it
should be treated as an "||", I suggest the grammar would something like
  expression_without_toplevel_or:
      "(" expression ")"      {...}
    | ...   -- Other stuff usable in expressions, but not OR.

  expression:
      expression_without_toplevel_or    {...}
    | expression OR expression {...}

  answer_statement:
    ANSWER expression WITH answer_button_list {...}

  answer_button_list:
        { /* empty */ }
    | answer_button_item {...}

  answer_button_item:
      expression_without_toplevel_or {...}

This way, when the parser sees the answer_statement, top level OR will be
treated as a series of independent expression_without_or expressions. But
one can enclose these with parenthesizes "(" ... ")", in which case the
OR's of the ... part will be viewed as part of the expression.

Something like that. A variation might be
  expression_without_or:
    | ...   -- Stuff usable in expressions, but not OR.

  expression:
      expression_without_or    {...}
    | expression OR expression {...}
    |  "(" expression ")"      {...}

  answer_statement:
    ANSWER expression WITH answer_button_list {...}

  answer_button_list:
        { /* empty */ }
    | answer_button_item {...}

  answer_button_item:
      expression_without_or {...}
    | "(" expression ")"    {...}

That is, I am not exactly sure how you would flip in the
    | "(" expression ")"             {...}
part -- where depends on what is exactly possible in languages.

But I think you should be able to resolve the ambiguities that way.

Also, it seems that the semantics of the two different OR's will be
different, so therefore I think that it will not suffice by merely fiddling
around with OR precedences. -- You need to write your grammar in such a way
that it is possible to insert the actions correctly.

Otherwise, I think this is a sign of poor language design. If you later
want to design your own scripting language, then you should avoid the
confusion that will inevitably arise by the "or"'s having different
semantic meaning.

  Hans Aberg