Parser expects objects block in non-fluents block.

[lchamp87x]

So I created my own rddl domain, which the parser finds no issues with. However, when I created a rddl instance file with non-fluents block and instance block and ran this through the parser, it kept getting a syntax error right at the start of the inner non-fluents block within the main non-fluents block. Here is the rddl instance file I am referring to,

and here is me calling the rddl parser and the resulting error,

So as I said, it wasn't liking the '{' proceeding the non-fluents header and gave me no clue why. Although, I noticed that almost every example of a non-fluents block that I have seen has a objects block preceding the inner non-fluents block. So on a hunch I tried adding this,

And this seems to pass through the parser fine with no errors giving,

I'll note, that I did try it with just an empty objects block,

objects {}; or,

objects {
};

and that didn't work.

Thus my conclusion is that for a non-fluents block, your parser specifically looks for a populated objects block inside of the non-fluents block just before the inner non-fluents block. I am assuming this is not by design because not all domains would need an objects block.

[thomaskeller79]

This is a general issue with the flex/bison specification of rddlsim (in src/rddl/parser/parser.{lex,cup}), which handles all of those optional elements by listing possible legal combinations. The simplest solution for this issue is to update the parser.cup file with an entry where the object section of the instance is omitted, but this would not help the general problem.

I would rather like to find a general solution that explicitly let's us define entries as optional and allows us to get away with a single specification instead of explicitly listing all possible combinations, but I don't know if I find the time to look into this (and I don't know enough about flex bison to judge how much work this is). Is there anyone else with the necessary flex/bison background who has the time to look into this?