Arithmetic with a `not` operand -- language spec issue or parser error? about csc488 HOT 7 CLOSED

Confirmed with the TA as being a valid expression that our parser must recognize.

from csc488.

I'm not sure how that can work without breaking precedence rules.

from csc488.

For instance:

1. not true * 1
2. not expression
3. expression

If we changed the behaviour then the precedence would change

1. not true * 1
2. expression * 1
3. expression

This does not seem valid.

from csc488.

We just need to add more rules, roughly:
mulexpr ::= mulexpr * notexpr
addexpr ::= addexpr + notexpr
Can we see if that solves the issue?

from csc488.

I have modified grammar which compiles and parses all test samples. It is a little ugly, however...

from csc488.

I think I'm going to close this and go with "won't fix".

We can justify this in the documentation in the discussion of the failing test case. The added complexity in the grammar is not worth the trouble. While it is perhaps syntactically more valid it is certainly not semantically valid. So it would never be a problem in practice.

I'm going to just revert the commit. People can find the fix in the commit history if they have to.

If anyone has a more elegant solution they are welcome to commit it.

from csc488.

Kay. I was actually pushing for a "won't fix" by showing just how screwed up the fix would have to be.

from csc488.