Doubt about Definition 15 (Recursion Restriction) of GDL Spe

Yes you are right. I am trying to create a robust parser of GDL with Bison. Even though role, input, etc are reserved relations, if I type (role (role robot)) into online gamechecker it does not give me any errors. Is this correct?? I believe there should be a formalized construct for any language.

hummm... I searched a little I didn't find any such rule. But I guess for code readability at least reserved keywords should be reserved. As role should only be used as relation and only with 1 argument to it. Comments??

No its not bound. "not" is not the same as logical negation. It has a negation as failure semantics.

AFAIK, there is no rule preventing the same symbol to be used both as a relation and as function or even for several relations or functions of different arity. The specification of GDL does not say anything about that. Anyway, it should probably be avoided when writing game descriptions because it is confusing to read and may break some players. In my code I typically try support all these cases but print a warning message when I detect them.

Yes the interesting question would be what restrictions do we have in GDL semantics?? Same symbol can be used as both function and relations or even several relations or functions of different arity.
Only restriction I can think of is goal relation or arity 2 has to have number or variable as second argument. So that goal values can be compared.
What other restriction do we have??

The GDL spec (which you linked to in your original post) says, in Definition 16, "A set of relation constants with associated arity" and "A set of function constants with associated arity". I read that as saying that a given relation constant or function constant should have only one arity associated with it, and this is a restriction the StaticValidator checks.

"not", "or", and "distinct" can't appear in the head because they're just part of the Datalog variant that GDL is embedded in (much like the "<=" operator); they aren't sentences, unlike the other keywords. You may want to get to know the structure of the Gdl classes in the GGP-Base codebase:
- A rule has a sentence as its head and literals in the body
- A literal may be a sentence or an "or", "not", or "distinct"
- An "or" has literals as its contents
- A "not" has a literal as its contents, though arguably it should only be allowed to have a sentence as its contents
- A "distinct" has terms as its contents
- A sentence may be a relation or a proposition, depending on whether its arity is 0, but this usually doesn't matter; it has a constant as its name, and if it's a relation, it has terms in its body
- A term may be a constant, variable, or function
- A function has a constant as a name and terms in its body
More details/examples here: alloyggp.blogspot.com/2013/02/a-quick-guide-to-gdl-terminology.html

"If role/1, base/1, input/2 and init/1 appears as head, does/2 and true/1 cannot appear as premises." It's a little more restrictive than that; there shouldn't even be any recursive dependencies from role/init/base/input on true/does. They should be fixed and not depend on the state of the game.

In fact, "role" should not be in the head of a rule at all. That would mess up the way the GGP communication protocol depends on the ordering of the roles within the game.

As for defining legal/goal/terminal "in terms of true", this is just loosely saying that they're allowed to depend on the current state of the game. They may do so directly or indirectly, or not at all. You can think of it like a function on the true state; you can use the state or ignore it in your function output, but you're not allowed to use the "does" contents, since those aren't known to you. Only "next" can use "does", and it can also use "true".

Having a game that is terminal in its initial state is pretty useless, though I don't know that it's ever been called out as being illegal.

Incidentally, I found that implementing and testing a PropNetStateMachine helped me understand these relationships better.

So I have finally fixed the grammar I am going to use (after lot of revisions).

---

terminals:
Obracket :- ")"
Cbracket :- "("
role :- "role"
base :- "base"
input :- "input"
and like this all reserved keywords are terminals
id :- any symbols appearing except reserved keywords, variables and numbers
num :- any number
var :- variable
clause_command :- "<="

S                : Fact S
S                : Clause S
S                : %empty

Fact            : Obracket role Ground_term Cbracket
Fact            : Obracket base Ground_term Cbracket
Fact            : Obracket input Ground_term Ground_term Cbracket
Fact            : Obracket init Ground_term Cbracket
Fact            : Obracket goal Ground_term num Cbracket
Fact            : Obracket next Ground_term Cbracket
Fact            : Obracket legal Ground_term Ground_term Cbracket
Fact            : terminal
Fact            : Obracket Id_num Ground_term Ground_terms Cbracket
Fact            : Id_num

Ground_term    : Obracket Id_num Ground_term Ground_terms Cbracket
Ground_term    : Id_num

Ground_terms    : Ground_term Ground_terms
Ground_terms    : %empty

Id_num    : id
Id_num    : num

Clause    : Obracket clause_command Head ORelation Relations Cbracket

Head    : Obracket role Term Cbracket
Head    : Obracket base Term Cbracket
Head    : Obracket input Term Term Cbracket
Head    : Obracket init Term Cbracket
Head    : Obracket legal Term Term Cbracket
Head    : Obracket goal Term Num_var Cbracket
Head    : Obracket next Term Cbracket
Head    : terminal
Head    : Id_num
Head    : Obracket Term Terms Cbracket

ORelation    : Obracket role CTerm Cbacket
ORelation    : Obracket base CTerm Cbracket
ORelation    : Obracket input CTerm Cbracket
ORelation    : Obracket init CTerm Cbracket
ORelation    : Obracket goal CTerm CTerm Cbracket
ORelation    : Obracket next CTerm Cbracket
ORelation    : Obracket legal CTerm CTerm Cbracket
ORelation    : terminal
ORelation    : Obracket does CTerm CTerm Cbracket
ORelation    : Obracket not ORelation Cbracket
ORelation    : Obracket or ORelation ORelations Cbracket
ORelation    : Obracket distinct CTerm CTerm Cbracket
ORelation    : Obracket true CTrem CTerm Cbracket
ORelation    : Obracket Id_num ORelation ORelations Cbracket
ORelation    : Id_num

ORelations    : ORelation ORelations
ORelations    : %empty

Term    : Obracket Id_num Term Terms Cbracket
Term    : Id_num
Term    : var

Terms    : Term Terms
Terms    : %empty

CTerm    : Obracket Id_num CTerm CTerms Cbracket
CTerm    : Id_num
CTerm    : var

CTerms    : CTerm CTerms
CTerms    : %empty

Num_var    : num
Num_var    : var

---

The above grammar is modified to produce following error -

1) With the help of symbol table using relation of function with more than one arity produces error.
2) With the help of symbol table produces error if symbol is used for both function and relation
3) Stratified Negation and other errors mentioned in GDL spec can be detected with symbol table and dependency graph
4) All the semantical errors.. such as true, does, not etc. cannot appear as head
5) Goal relation can only accept number as its second argument. (Or it can be a variable in which case error detection is little difficult. Haven't found a way to do so. )

The above grammer is modified to produce following warnings -

1) Is Defined?? :- A symbol is defined if it appear in at least one fact or head of one rule.
2) terminal and goal relation appearing as a fact

Any more errors and warnings that can be added??