[M3devel] A possible grammar overstrictness or ambiguity problem

[Daniel Alejandro Benavides D.]

Hi all:
Thanks for the hints I have just re-read your message, I think you can purpose a multi-value suitable solution:
IF NOT a=b, 
which is in semantic analysis 
same as 
IF b = NOT a
then I think would make the case for the "fix" or vice versa, but I think language definition has no assumptions over this (or at least I can't see them).

I was thinking that we could sort of avoid this by defining a core grammar, in top of which we can put the rest, but this is the harder solution as you say. But I'm thinking along this lines, since I'm a true proposer of Baby Modula-3 be in some form (along the lines) in the Modula-3 language definition.

I wish we could talk more than in typing texts by email, but the other diea I had about this is to introduce animations (Obliq, Trestle, whatever fills our purposes, or better, Juno ones) of the Modula-3 SPWM3 book, since most of the interfaces are in the code base, I think by making a Baby Modula-3 implementation we could insert it in the Chapter 1, in same way (succinctly because Baby is small by language definition) and by allow information on it to be explained incrementally by the language itself in a cool manner.

OK, I will let you know the details, as soon I get into it, but hope you can give more hints or some opinion on anyones behalf.

Thanks in advance

--- El sáb, 5/5/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] A possible grammar overstrictness or ambiguity problem
> Para: m3devel at elegosoft.com
> Fecha: sábado, 5 de mayo, 2012 18:27
> 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
> >
>