[M3devel] A possible grammar overstrictness or ambiguity problem

[Rodney M. Bates]

Hmm, interesting.  If the expression were  NOT a = b, (and no precedence rules),
there would be two ways to parenthesize: (NOT a) = b and NOT (a = b), an
ambiguity.  Making NOT have lower precedence than = resolves this in favor
of the latter.  Equivalently, the grammar is written so that = demands each
of its operands be E4 or higher, which NOT E3 is not, it's an E2.  This fixes
this and other potential ambiguities.

But in the example, since NOT is only a prefix operator, there is only way
to parenthesize, i.e. nothing like (b =) NOT a.  So the precedence would not be
necessary in this case.  But the grammar is written to apply the precedence
rule consistently, leaving the unparenthesized version b = NOT a
underivable.  Overly strict, but maybe not worth the trouble to weaken.

An interesting exercise that I do not have the energy to do would be to
rewrite the M3 expression grammar to allow b = NOT a, without introducing
ambiguity elsewhere.  And make it work on the other prefix operators + and -.
Would be good for a textbook.

I don't think postfix operators (Selector in the grammar) can get into
a counterpart problem because they have the highest precedence.

On 05/04/2012 04:30 PM, Daniel Alejandro Benavides D. wrote:
> Hi all:
> Please take a look at p. 18:
> http://math.guc.edu.eg/Wafik/Characterizing%20Unambiguity.pdf
>
> I have recreated in a small program not particulary useful to you but to the example:
> ///////////////////////// Main.m3 /////////////////////////////////
> MODULE Main;
> VAR a, b :=FALSE;
>
> BEGIN
>
> IF b = (NOT a)
>   THEN a:=b;
> END
>
> END Main.
>
> It works as theory expresses but in my small program's alphabet it's overstrict, isn't it? Line 6 is a bad expression without parenthesis.
>
>   Thanks in advance
>