question about grouping of operators

[fdouglis]

I had a lot of trouble trying to sort out why a fluent was being set when I felt it shouldn't be. Eventually I tried adding parens around "~exists_....[]" and that changed the behavior. I would expect that ~exists_ should map the ~ most closely around exists_ and the parens would be unnecessary.

I wanted to post a simple example to demonstrate it, and I couldn't come up with exactly the same state that would produce that particular problem. But I found a different one, which could be related, and figured I'd start with that. (Rather convoluted as I was trying to demonstrate a particular oddity, but it should demonstrate what I saw.) This is a fairly simple example, building on the "blowup" example I posted earlier. I was getting a run-time error, but surprisingly, when I commented out little by little, it was the one with the extra parens added that caused some sort of mismatch in operator types. Specifically, I get

Exception in thread "main" rddl.EvalException: Both values in object/enum comparison == (true/class java.lang.Boolean,@b/class rddl.RDDL$ENUM_VAL) must be object/enum

If I comment out the second of the two similar lines, as noted in the RDDL source, it runs fine. AFAIK the difference is that extra set of parens. Maybe I'm confused, but maybe the parser is, so I'm posting here.

test.rddl.txt

[fdouglis]

I encountered a related issue.

forall_{?a:a}[sum_{?x:x}[foo(?a,?x) + bar(?a,?x)] <= 1];

seems to generate a parser error. If I wrap the sum{}[] in parens it is happy. Shouldn't sum_{}[..] bind closely as a single thing even without parens around it? And in any case this is a much simpler example of the parser requiring parens unexpectedly than the longer test case I posted last week.