%----v6.0.0.0 (TPTP version.internal development number)
%------------------------------------------------------------------------------
%----README ... this header provides important meta- and usage information
%----
%----Intended uses of the various parts of the TPTP syntax are explained
%----in the TPTP technical manual, linked from www.tptp.org.
%----
%----Four kinds of separators are used, to indicate different types of rules:
%----  ::= is used for regular grammar rules, for syntactic parsing.
%----  :== is used for semantic grammar rules. These define specific values
%----      that make semantic sense when more general syntactic rules apply.
%----  ::- is used for rules that produce tokens.
%----  ::: is used for rules that define character classes used in the
%----       construction of tokens.
%----
%----White space may occur between any two tokens. White space is not specified
%----in the grammar, but there are some restrictions to ensure that the grammar
%----is compatible with standard Prolog: a <TPTP_file> should be readable with
%----read/1.
%----
%----The syntax of comments is defined by the <comment> rule. Comments may
%----occur between any two tokens, but do not act as white space. Comments
%----will normally be discarded at the lexical level, but may be processed
%----by systems that understand them (e.g., if the system comment convention
%----is followed).
%----
%----Four languages are defined first - THF, TFF, FOF, and CNF. Depending on
%----your need, you can implement just the one(s) you need. The common rules
%----for atoms, terms, etc, come after the definitions of the languages, and
%----they are all needed for all four languages (except for the core THF0,
%----which is a defined subset of THF).
%----Top of Page---------------------------------------------------------------
%----Files. Empty file is OK.
<TPTP_file>          ::= <TPTP_input>*
<TPTP_input>         ::= <annotated_formula> | <include>

%----Formula records
<annotated_formula>  ::= <thf_annotated> | <tff_annotated> | <fof_annotated> |
                         <cnf_annotated> | <tpi_annotated
%----Future languages may include ...  english | efof | tfof | mathml | ...
<tpi_annotated>      ::= tpi(<name>,<formula_role>,<tpi_formula><annotations>).
<tpi_formula>        ::= <fof_formula>
<thf_annotated>      ::= thf(<name>,<formula_role>,<thf_formula><annotations>).
<tff_annotated>      ::= tff(<name>,<formula_role>,<tff_formula><annotations>).
<fof_annotated>      ::= fof(<name>,<formula_role>,<fof_formula><annotations>).
<cnf_annotated>      ::= cnf(<name>,<formula_role>,<cnf_formula><annotations>).
<annotations>        ::= ,<source><optional_info> | <null>
%----In derivations the annotated formulae names must be unique, so that
%----parent references (see <inference_record>) are unambiguous.

%----Types for problems.
%----Note: The previous <source_type> from ...
%----   <formula_role> ::= <user_role>-<source>
%----... is now gone. Parsers may choose to be tolerant of it for backwards
%----compatibility.
<formula_role>       ::= <lower_word>
<formula_role>       :== axiom | hypothesis | definition | assumption |
                         lemma | theorem | conjecture | negated_conjecture |
                         plain | fi_domain | fi_functors | fi_predicates |
                         type | unknown
%----"axiom"s are accepted, without proof. There is no guarantee that the
%----axioms of a problem are consistent.
%----"hypothesis"s are assumed to be true for a particular problem, and are
%----used like "axiom"s.
%----"definition"s are intended to define symbols. They are either universally
%----quantified equations, or universally quantified equivalences with an
%----atomic lefthand side. They can be treated like "axiom"s.
%----"assumption"s can be used like axioms, but must be discharged before a
%----derivation is complete.
%----"lemma"s and "theorem"s have been proven from the "axiom"s. They can be
%----used like "axiom"s in problems, and a problem containing a non-redundant
%----"lemma" or theorem" is ill-formed. They can also appear in derivations.
%----"theorem"s are more important than "lemma"s from the user perspective.
%----"conjecture"s are to be proven from the "axiom"(-like) formulae. A problem
%----is solved only when all "conjecture"s are proven.
%----"negated_conjecture"s are formed from negation of a "conjecture" (usually
%----in a FOF to CNF conversion).
%----"plain"s have no specified user semantics.
%----"fi_domain", "fi_functors", and "fi_predicates" are used to record the
%----domain, interpretation of functors, and interpretation of predicates, for
%----a finite interpretation.
%----"type" defines the type globally for one symbol; treat as $true.
%----"unknown"s have unknown role, and this is an error situation.
%----Top of Page---------------------------------------------------------------
%----THF formulae.
<thf_formula>        ::= <thf_logic_formula> | <thf_sequent>
<thf_logic_formula>  ::= <thf_binary_formula> | <thf_unitary_formula> |
                         <thf_type_formula> | <thf_subtype>
<thf_binary_formula> ::= <thf_binary_pair> | <thf_binary_tuple> |
%----<thf_binary_type> should not be used at the top level. It is needed here
%----for other uses of <thf_logic_formula>.
                         <thf_binary_type>
%----Only some binary connectives can be written without ()s.
%----There's no precedence among binary connectives
<thf_binary_pair>    ::= <thf_unitary_formula> <thf_pair_connective>
                         <thf_unitary_formula>
<thf_binary_tuple>   ::= <thf_or_formula> | <thf_and_formula> |
                         <thf_apply_formula>
<thf_or_formula>     ::= <thf_unitary_formula> <vline> <thf_unitary_formula> |
                         <thf_or_formula> <vline> <thf_unitary_formula>
<thf_and_formula>    ::= <thf_unitary_formula> & <thf_unitary_formula> |
                         <thf_and_formula> & <thf_unitary_formula>
<thf_apply_formula>  ::= <thf_unitary_formula> @ <thf_unitary_formula> |
                         <thf_apply_formula> @ <thf_unitary_formula>
%----<thf_unitary_formula> are in ()s or do not have a <binary_connective> at
%----the top level. Essentially, any lambda expression that "has enough ()s" to
%----be used inside a larger lambda expression. However, lambda notation might
%----not be used.
<thf_unitary_formula> ::= <thf_quantified_formula> | <thf_unary_formula> |
                         <thf_atom> | <thf_conditional> | <thf_let> |
                         (<thf_logic_formula>)
<thf_quantified_formula> ::= <thf_quantifier> [<thf_variable_list>] :
                         <thf_unitary_formula>
%----@ (denoting apply) is left-associative and lambda is right-associative.
%----^ [X] : ^ [Y] : f @ g (where f is a <thf_apply_formula> and g is a
%----<thf_unitary_formula>) should be parsed as: (^ [X] : (^ [Y] : f)) @ g.
%----That is, g is not in the scope of either lambda.
<thf_variable_list>  ::= <thf_variable> | <thf_variable>,<thf_variable_list>
<thf_variable>       ::= <thf_typed_variable> | <variable>
<thf_typed_variable> ::= <variable> : <thf_top_level_type>
%----Unary connectives bind more tightly than binary. The negated formula
%----must be ()ed because a ~ is also a term.
<thf_unary_formula>  ::= <thf_unary_connective> (<thf_logic_formula>)
%----<thf_atom> can also be <defined_type> | <defined_plain_formula> |
%----<system_type> | <system_atomic_formula>, but they are syntactically
%----captured by <term>.
<thf_atom>           ::= <term> | <thf_conn_term>
<thf_conditional>    ::= $ite_f(<thf_logic_formula>,<thf_logic_formula>,
                         <thf_logic_formula>)
%----This is the original, but not working
<thf_let>            ::= $let_tf(<thf_let_term_defn>,<thf_formula>) |
                         $let_ff(<thf_let_formula_defn>,<thf_formula>)
<thf_let_term_defn>  ::= <thf_quantified_formula>
<thf_let_formula_defn> ::= <thf_quantified_formula>
<thf_let_term_defn>  :== ! [<thf_variable_list>] : <thf_let_term_binding> |
                         <thf_let_term_binding>
<thf_let_term_binding> :== <thf_let_lhs> = <thf_unitary_formula> |
                         (<thf_let_term_binding>)
<thf_let_formula_defn> :== ! [<thf_variable_list>] : <thf_let_formula_binding> |
                         <thf_let_formula_binding>
<thf_let_formula_binding> :== <thf_let_lhs> <=> <thf_unitary_formula> |
                         (<thf_let_formula_binding>)
%----A <thf_let_lhs> must be a <constant>, or an application of a <constant> to 
%----pairwise distinct variables that appear in the <thf_variable_list>.
<thf_let_lhs>        :== <constant> | <thf_apply_formula>

%----This is my experimentation
% <thf_let>            ::= <thf_let_binder>(<thf_let_defn>,<thf_formula>)
% <thf_let_binder>     ::= $let_tf | $let_ff
% <thf_let_defn>       ::= <thf_unitary_formula>
% <thf_let_defn>       :== ! [<thf_variable_list>] : <thf_let_binding> |
%                          <thf_let_binding>
% <thf_let_binding>    ::= <thf_let_term_binding> | <thf_let_formula_binding>
% <thf_let_term_binding> ::= <thf_let_lhs> = <thf_unitary_formula>
% <thf_let_formula_binding> ::= <thf_let_lhs> <=> <thf_unitary_formula>
% %----A <thf_let_lhs> must be a <constant>, or an application of a <constant> to 
% %----pairwise distinct variables that appear in the <thf_variable_list>.
% <thf_let_lhs>        ::= <constant> | <thf_apply_formula>

%----A <thf_type_formula> is an assertion that the formula is in this type.
<thf_type_formula>   ::= <thf_typeable_formula> : <thf_top_level_type>
<thf_typeable_formula> ::= <thf_atom> | (<thf_logic_formula>)
<thf_subtype>        ::= <constant> <subtype_sign> <constant>
%----In a formula with role 'type', <thf_type_formula> is a global declaration
%----that <constant> is in this thf_top_level_type>, i.e., the rule is ...
<thf_type_formula>   :== <constant> : <thf_top_level_type>
%----All symbols must be typed exactly one before use, and all atomic types
%----must be declared (of type $tType) before use.

%----<thf_top_level_type> appears after ":", where a type is being specified
%----for a term or variable. <thf_unitary_type> includes <thf_unitary_formula>,
%----so the syntax allows just about any lambda expression with "enough"
%----parentheses to serve as a type. The expected use of this flexibility is
%----parametric polymorphism in types, expressed with lambda abstraction.
%----Mapping is right-associative: o > o > o means o > (o > o).
%----Xproduct is left-associative: o * o * o means (o * o) * o.
%----Union is left-associative: o + o + o means (o + o) + o.
<thf_top_level_type> ::= <thf_logic_formula>
<thf_unitary_type>   ::= <thf_unitary_formula>
<thf_binary_type>    ::= <thf_mapping_type> | <thf_xprod_type> |
                         <thf_union_type>
<thf_mapping_type>   ::= <thf_unitary_type> <arrow> <thf_unitary_type> |
                         <thf_unitary_type> <arrow> <thf_mapping_type>
<thf_xprod_type>     ::= <thf_unitary_type> <star> <thf_unitary_type> |
                         <thf_xprod_type> <star> <thf_unitary_type>
<thf_union_type>     ::= <thf_unitary_type> <plus> <thf_unitary_type> |
                         <thf_union_type> <plus> <thf_unitary_type>

%----Sequents using the Gentzen arrow
<thf_sequent>        ::= <thf_tuple> <gentzen_arrow> <thf_tuple> |
                         (<thf_sequent>)

%----<thf_tuple>s are syntactic sugar for lists, either the empty list, or a
%----term as the head and a list as a tail. The internal representation is not
%----specified, but see the Wikipedia page ...
%----    http://en.wikipedia.org/wiki/Church_encoding#List_encodings
%----for some possibilities.
<thf_tuple>          ::= [] | [<thf_tuple_list>]
<thf_tuple_list>     ::= <thf_logic_formula> |
                         <thf_logic_formula>,<thf_tuple_list>

%----Top of Page---------------------------------------------------------------
%----TFF formulae.
%----TFF is like FOF except that predicate and function symbols must be typed
%----exactly once at top level (with formula role "type"), and variables must
%----be typed when they are bound in quantifier lists. <atomic_formula>s are
%----just like FOF. See the proposal linked from the TPTP web page for details
%----of the semantics.
<tff_formula>        ::= <tff_logic_formula> | <tff_typed_atom> | <tff_sequent>
%----This is where <tff_subtype> used to be
<tff_logic_formula>  ::= <tff_binary_formula> | <tff_unitary_formula>
<tff_binary_formula> ::= <tff_binary_nonassoc> | <tff_binary_assoc>
<tff_binary_nonassoc> ::= <tff_unitary_formula> <binary_connective>
                         <tff_unitary_formula>
<tff_binary_assoc>   ::= <tff_or_formula> | <tff_and_formula>
<tff_or_formula>     ::= <tff_unitary_formula> <vline> <tff_unitary_formula> |
                         <tff_or_formula> <vline> <tff_unitary_formula>
<tff_and_formula>    ::= <tff_unitary_formula> & <tff_unitary_formula> |
                         <tff_and_formula> & <tff_unitary_formula>
<tff_unitary_formula> ::= <tff_quantified_formula> | <tff_unary_formula> |
                         <atomic_formula> | <tff_conditional> | <tff_let> |
                         (<tff_logic_formula>)
<tff_quantified_formula> ::= <fol_quantifier> [<tff_variable_list>] :
                         <tff_unitary_formula>
<tff_variable_list>  ::= <tff_variable> | <tff_variable>,<tff_variable_list>
<tff_variable>       ::= <tff_typed_variable> | <variable>
<tff_typed_variable> ::= <variable> : <tff_atomic_type>
<tff_unary_formula>  ::= <unary_connective> <tff_unitary_formula> |
                         <fol_infix_unary>
<tff_conditional>    ::= $ite_f(<tff_logic_formula>,<tff_logic_formula>,
                         <tff_logic_formula>)
<tff_let>            ::= $let_tf(<tff_let_term_defn>,<tff_formula>) |
                         $let_ff(<tff_let_formula_defn>,<tff_formula>)
%----The LHS of a <tff_let_term_binding> or a <tff_let_formula_binding> must be
%----flat with pairwise distinct variable arguments, and the variables on the
%----LHS must be those bound in the <tff_variable_list>.
<tff_let_term_defn>  ::= ! [<tff_variable_list>] : <tff_let_term_defn> |
                         <tff_let_term_binding>
<tff_let_term_binding> ::= <term> = <term> | (<tff_let_term_binding>)
<tff_let_formula_defn> ::= ! [<tff_variable_list>] : <tff_let_formula_defn> |
                         <tff_let_formula_binding>
<tff_let_formula_binding> ::= <atomic_formula> <=> <tff_unitary_formula> |
                         (<tff_let_formula_binding>)

<tff_sequent>        ::= <tff_tuple> <gentzen_arrow> <tff_tuple> |
                         (<tff_sequent>)
<tff_tuple>          ::= [] | [<tff_tuple_list>]
<tff_tuple_list>     ::= <tff_logic_formula> |
                         <tff_logic_formula>,<tff_tuple_list>

%----<tff_typed_atom> can appear only at top level
<tff_typed_atom>     ::= <tff_untyped_atom> : <tff_top_level_type> |
                         (<tff_typed_atom>)
<tff_untyped_atom>   ::= <functor> | <system_functor>
%----Subtypes have been removed
%<tff_subtype>        ::= <tff_untyped_atom> <subtype_sign> <tff_untyped_atom> |
%                         (<tff_subtype>)

%----See <thf_top_level_type> for commentary. <tff_quantified_type> is TFF1.
<tff_top_level_type> ::= <tff_atomic_type> | <tff_mapping_type> |
                         <tff_quantified_type> | (<tff_top_level_type>)
<tff_quantified_type> ::= !> [<tff_variable_list>] : <tff_monotype>
<tff_monotype>       ::= <tff_atomic_type> | (<tff_mapping_type>)
<tff_unitary_type>   ::= <tff_atomic_type> | (<tff_xprod_type>)
<tff_atomic_type>    ::= <atomic_word> | <defined_type> | 
                         <atomic_word>(<tff_type_arguments>) | <variable>
<tff_type_arguments> ::= <tff_atomic_type> |
                         <tff_atomic_type>,<tff_type_arguments>
%----For consistency with <thf_unitary_type> (the analogue in thf),
%----<tff_atomic_type> should also allow (<tff_atomic_type>), but that causes
%----ambiguity.
%----For Josef Urban, change <atomic_word> to <tff_unitary_formula>, and leave
%----out <defined_type> (to avoid conflict on <atomic_defined_word>.
<tff_mapping_type>   ::= <tff_unitary_type> <arrow> <tff_atomic_type>
<tff_xprod_type>     ::= <tff_unitary_type> <star> <tff_atomic_type> |
                         <tff_xprod_type> <star> <tff_atomic_type>

%----The types of the <defined_atom>s and <defined_prop>s are:
%----    <real> : $real
%----    <rational> : $rat
%----    <signed_integer> : $int
%----    <unsigned_integer> : $int
%----    <distinct_object> : $i
%----    $true : $o
%----    $false : $o

%----Top of Page---------------------------------------------------------------
%----FOF formulae.
<fof_formula>        ::= <fof_logic_formula> | <fof_sequent>
<fof_logic_formula>  ::= <fof_binary_formula> | <fof_unitary_formula>
%----Future answer variable ideas | <answer_formula>
<fof_binary_formula> ::= <fof_binary_nonassoc> | <fof_binary_assoc>
%----Only some binary connectives are associative
%----There's no precedence among binary connectives
<fof_binary_nonassoc> ::= <fof_unitary_formula> <binary_connective>
                         <fof_unitary_formula>
%----Associative connectives & and | are in <binary_assoc>
<fof_binary_assoc>   ::= <fof_or_formula> | <fof_and_formula>
<fof_or_formula>     ::= <fof_unitary_formula> <vline> <fof_unitary_formula> |
                         <fof_or_formula> <vline> <fof_unitary_formula>
<fof_and_formula>    ::= <fof_unitary_formula> & <fof_unitary_formula> |
                         <fof_and_formula> & <fof_unitary_formula>
%----<fof_unitary_formula> are in ()s or do not have a <binary_connective> at
%----the top level.
<fof_unitary_formula> ::= <fof_quantified_formula> | <fof_unary_formula> |
                         <atomic_formula> | (<fof_logic_formula>)
<fof_quantified_formula> ::= <fol_quantifier> [<fof_variable_list>] :
                         <fof_unitary_formula>
<fof_variable_list>  ::= <variable> | <variable>,<fof_variable_list>
<fof_unary_formula>  ::= <unary_connective> <fof_unitary_formula> |
                         <fol_infix_unary>

%----Top of Page---------------------------------------------------------------
%----This section is the FOFX syntax. Not yet in use.
% <fof_let>            ::= := [<fof_let_list>] : <fof_unitary_formula>
% <fof_let_list>       ::= <fof_defined_var> |
%                          <fof_defined_var>,<fof_let_list>
% <fof_defined_var>    ::= <variable> := <fof_logic_formula> |
%                          <variable> :- <term> | (<fof_defined_var>)
%
% <fof_conditional>    ::= $ite_f(<fof_logic_formula>,<fof_logic_formula>,
%                          <fof_logic_formula>)
%
% <fof_conditional_term> ::= $ite_t(<fof_logic_formula>,<term>,<term>)

<fof_sequent>        ::= <fof_tuple> <gentzen_arrow> <fof_tuple> |
                         (<fof_sequent>)

<fof_tuple>          ::= [] | [<fof_tuple_list>]
<fof_tuple_list>     ::= <fof_logic_formula> |
                         <fof_logic_formula>,<fof_tuple_list>

%----Top of Page---------------------------------------------------------------
%----CNF formulae (variables implicitly universally quantified)
<cnf_formula>        ::= (<disjunction>) | <disjunction>
<disjunction>        ::= <literal> | <disjunction> <vline> <literal>
<literal>            ::= <atomic_formula> | ~ <atomic_formula> |
                         <fol_infix_unary>
%----Top of Page---------------------------------------------------------------
%----Special formulae
<thf_conn_term>      ::= <thf_pair_connective> | <assoc_connective> |
                         <thf_unary_connective>
<fol_infix_unary>    ::= <term> <infix_inequality> <term>

%----Connectives - THF
<thf_quantifier>     ::= <fol_quantifier> | ^ | !> | ?* | @+ | @-
<thf_pair_connective> ::= <infix_equality> | <infix_inequality> |
                         <binary_connective>
<thf_unary_connective> ::= <unary_connective> | !! | ??
%----Connectives - THF and TFF
<subtype_sign>       ::= <less_sign><less_sign>
%----Connectives - FOF
<fol_quantifier>     ::= ! | ?
<binary_connective>  ::= <=> | => | <= | <~> | ~<vline> | ~&
<assoc_connective>   ::= <vline> | &
<unary_connective>   ::= ~
%----The seqent arrow
<gentzen_arrow>      ::= -->

%----Types for THF and TFF
<defined_type>       ::= <atomic_defined_word>
<defined_type>       :== $oType | $o | $iType | $i | $tType |
                         $real | $rat | $int
%----$oType/$o is the Boolean type, i.e., the type of $true and $false.
%----$iType/$i is non-empty type of individuals, which may be finite or
%----infinite. $tType is the type of all types. $real is the type of <real>s.
%----$rat is the type of <rational>s. $int is the type of <signed_integer>s
%----and <unsigned_integer>s.
<system_type>        :== <atomic_system_word>

%----First order atoms
<atomic_formula>     ::= <plain_atomic_formula> | <defined_atomic_formula> |
                         <system_atomic_formula>
<plain_atomic_formula> ::= <plain_term>
<plain_atomic_formula> :== <proposition> | <predicate>(<arguments>)
<proposition>        :== <predicate>
<predicate>          :== <atomic_word>
%----Using <plain_term> removes a reduce/reduce ambiguity in lex/yacc.
%----Note: "defined" means a word starting with one $ and "system" means $$.
<defined_atomic_formula> ::= <defined_plain_formula> | <defined_infix_formula>
<defined_plain_formula> ::= <defined_plain_term>
<defined_plain_formula> :== <defined_prop> | <defined_pred>(<arguments>)
<defined_prop>       :== <atomic_defined_word>
<defined_prop>       :== $true | $false
%----Pure CNF should not use $true or $false in problems, and use $false only
%----at the roots of a refutation.
<defined_pred>       :== <atomic_defined_word>
<defined_pred>       :== $distinct |
                         $less | $lesseq | $greater | $greatereq |
                         $is_int | $is_rat
%----$distinct means that each of it's constant arguments are pairwise !=. It 
%----is part of the TFF syntax. It can be used only as a fact, not under any 
%----connective.
<defined_infix_formula>  ::= <term> <defined_infix_pred> <term>
<defined_infix_pred> ::= <infix_equality>
<infix_equality>     ::= =
<infix_inequality>   ::= !=
%----Some systems still interpret equal/2 as equality. The use of equal/2
%----for other purposes is therefore discouraged. Please refrain from either
%----use. Use infix '=' for equality. Note: <term> != <term> is equivalent
%----to ~ <term> = <term>
%----System terms have system specific interpretations
<system_atomic_formula> ::= <system_term>
%----<system_atomic_formula>s are used for evaluable predicates that are
%----available in particular tools. The predicate names are not controlled
%----by the TPTP syntax, so use with due care. The same is true for
%----<system_term>s.

%----First order terms
<term>               ::= <function_term> | <variable> | <conditional_term> |
                         <let_term>
<function_term>      ::= <plain_term> | <defined_term> | <system_term>
<plain_term>         ::= <constant> | <functor>(<arguments>)
<constant>           ::= <functor>
<functor>            ::= <atomic_word>
%----Defined terms have TPTP specific interpretations
<defined_term>       ::= <defined_atom> | <defined_atomic_term>
<defined_atom>       ::= <number> | <distinct_object>
<defined_atomic_term> ::= <defined_plain_term>
%----None yet            | <defined_infix_term>
%----None yet <defined_infix_term> ::= <term> <defined_infix_func> <term>
%----None yet <defined_infix_func> ::=
<defined_plain_term> ::= <defined_constant> | <defined_functor>(<arguments>)
<defined_constant>   ::= <defined_functor>
<defined_constant>   :== <defined_type>
<defined_functor>    ::= <atomic_defined_word>
<defined_functor>    :== $uminus | $sum | $difference | $product |
                         $quotient | $quotient_e | $quotient_t | $quotient_f |
                         $remainder_e | $remainder_t | $remainder_f |
                         $floor | $ceiling | $truncate | $round |
                         $to_int | $to_rat | $to_real
%----System terms have system specific interpretations
<system_term>        ::= <system_constant> | <system_functor>(<arguments>)
<system_constant>    ::= <system_functor>
<system_functor>     ::= <atomic_system_word>
%----Variables, and only variables, start with uppercase
<variable>           ::= <upper_word>
%----Arguments recurse back up to terms (this is the FOF world here)
<arguments>          ::= <term> | <term>,<arguments>
%----Principal symbols are predicates, functions, variables
<principal_symbol>   :== <functor> | <variable>
%----Conditional terms should be used by only TFF.
<conditional_term>   ::= $ite_t(<tff_logic_formula>,<term>,<term>)
%----Let terms should be used by only TFF. $let_ft is for use when there is
%----a $ite_t in the <term>
<let_term>           ::= $let_ft(<tff_let_formula_defn>,<term>) |
                         $let_tt(<tff_let_term_defn>,<term>)

%----Top of Page---------------------------------------------------------------
%----Formula sources
<source>             ::= <general_term>
<source>             :== <dag_source> | <internal_source> | <external_source> |
                         unknown | [<sources>]
%----Alternative sources are recorded like this, thus allowing representation
%----of alternative derivations with shared parts.
<sources>            :== <source> | <source>,<sources>
%----Only a <dag_source> can be a <name>, i.e., derived formulae can be
%----identified by a <name> or an <inference_record>
<dag_source>         :== <name> | <inference_record>
<inference_record>   :== inference(<inference_rule>,<useful_info>,
                         <inference_parents>)
<inference_rule>     :== <atomic_word>
%----Examples are        deduction | modus_tollens | modus_ponens | rewrite |
%                        resolution | paramodulation | factorization |
%                        cnf_conversion | cnf_refutation | ...
%----<inference_parents> can be empty in cases when there is a justification
%----for a tautologous theorem. In case when a tautology is introduced as
%----a leaf, e.g., for splitting, then use an <internal_source>.
<inference_parents>  :== [] | [<parent_list>]
<parent_list>        :== <parent_info> | <parent_info>,<parent_list>
<parent_info>        :== <source><parent_details>
<parent_details>     :== :<general_list> | <null>
<internal_source>    :== introduced(<intro_type><optional_info>)
<intro_type>         :== definition | axiom_of_choice | tautology | assumption
%----This should be used to record the symbol being defined, or the function
%----for the axiom of choice
<external_source>    :== <file_source> | <theory> | <creator_source>
<file_source>        :== file(<file_name><file_info>)
<file_info>          :== ,<name> | <null>
<theory>             :== theory(<theory_name><optional_info>)
<theory_name>        :== equality | ac
%----More theory names may be added in the future. The <optional_info> is
%----used to store, e.g., which axioms of equality have been implicitly used,
%----e.g., theory(equality,[rst]). Standard format still to be decided.
<creator_source>     :== creator(<creator_name><optional_info>)
<creator_name>       :== <atomic_word>

%----Useful info fields
<optional_info>      ::= ,<useful_info> | <null>
<useful_info>        ::= <general_list>
<useful_info>        :== [] | [<info_items>]
<info_items>         :== <info_item> | <info_item>,<info_items>
<info_item>          :== <formula_item> | <inference_item> | <general_function>
%----Useful info for formula records
<formula_item>       :== <description_item> | <iquote_item>
<description_item>   :== description(<atomic_word>)
<iquote_item>        :== iquote(<atomic_word>)
%----<iquote_item>s are used for recording exactly what the system output about
%----the inference step. In the future it is planned to encode this information
%----in standardized forms as <parent_details> in each <inference_record>.
%----Useful info for inference records
<inference_item>     :== <inference_status> | <assumptions_record> |
                         <new_symbol_record> | <refutation>
<inference_status>   :== status(<status_value>) | <inference_info>
%----These are the success status values from the SZS ontology. The most
%----commonly used values are:
%----  thm - Every model of the parent formulae is a model of the inferred
%----        formula. Regular logical consequences.
%----  cth - Every model of the parent formulae is a model of the negation of
%----        the inferred formula. Used for negation of conjectures in FOF to
%----        CNF conversion.
%----  esa - There exists a model of the parent formulae iff there exists a
%----        model of the inferred formula. Used for Skolemization steps.
%----For the full hierarchy see the SZSOntology file distributed with the TPTP.
<status_value>       :== suc | unp | sap | esa | sat | fsa | thm | eqv | tac |
                         wec | eth | tau | wtc | wth | cax | sca | tca | wca |
                         cup | csp | ecs | csa | cth | ceq | unc | wcc | ect |
                         fun | uns | wuc | wct | scc | uca | noc
%----<inference_info> is used to record standard information associated with an
%----arbitrary inference rule. The <inference_rule> is the same as the
%----<inference_rule> of the <inference_record>. The <atomic_word> indicates
%----the information being recorded in the <general_list>. The <atomic_word>
%----are (loosely) set by TPTP conventions, and include esplit, sr_split, and
%----discharge.
<inference_info>     :== <inference_rule>(<atomic_word>,<general_list>)
%----An <assumptions_record> lists the names of assumptions upon which this
%----inferred formula depends. These must be discharged in a completed proof.
<assumptions_record> :== assumptions([<name_list>])
%----A <refutation> record names a file in which the inference recorded here
%----is recorded as a proof by refutation.
<refutation>         :== refutation(<file_source>)
%----A <new_symbol_record> provides information about a newly introduced symbol.
<new_symbol_record>  :== new_symbols(<atomic_word>,[<new_symbol_list>])
<new_symbol_list>    :== <principal_symbol> |
                         <principal_symbol>,<new_symbol_list>

%----Include directives
<include>            ::= include(<file_name><formula_selection>).
<formula_selection>  ::= ,[<name_list>] | <null>
<name_list>          ::= <name> | <name>,<name_list>

%----Non-logical data
<general_term>       ::= <general_data> | <general_data>:<general_term> |
                         <general_list>
<general_data>       ::= <atomic_word> | <general_function> |
                         <variable> | <number> | <distinct_object> |
                         <formula_data>
<general_function>   ::= <atomic_word>(<general_terms>)
%----A <general_data> bind() term is used to record a variable binding in an
%----inference, as an element of the <parent_details> list.
<general_data>       :== bind(<variable>,<formula_data>)
<formula_data>       ::= $thf(<thf_formula>) | $tff(<tff_formula>) |
                         $fof(<fof_formula>) | $cnf(<cnf_formula>) |
                         $fot(<term>)
<general_list>       ::= [] | [<general_terms>]
<general_terms>      ::= <general_term> | <general_term>,<general_terms>

%----General purpose
<name>               ::= <atomic_word> | <integer>
%----Integer names are expected to be unsigned
<atomic_word>        ::= <lower_word> | <single_quoted>
%----<single_quoted> tokens do not include their outer quotes, therefore the
%----<lower_word> <atomic_word> cat and the <single_quoted> <atomic_word> 'cat'
%----are the same. Quotes must be removed from a <single_quoted> <atomic_word>
%----if doing so produces a <lower_word> <atomic_word>. Note that <numbers>s
%----and <variable>s are not <lower_word>s, so '123' and 123, and 'X' and X,
%----are different.
<atomic_defined_word> ::= <dollar_word>
<atomic_system_word> ::= <dollar_dollar_word>
<number>             ::= <integer> | <rational> | <real>
%----Numbers are always interpreted as themselves, and are thus implicitly
%----distinct if they have different values, e.g., 1 != 2 is an implicit axiom.
%----All numbers are base 10 at the moment.
<file_name>          ::= <single_quoted>
<null>               ::=
%----Top of Page---------------------------------------------------------------
%----Rules from here on down are for defining tokens (terminal symbols) of the
%----grammar, assuming they will be recognized by a lexical scanner.
%----A ::- rule defines a token, a ::: rule defines a macro that is not a
%----token. Usual regexp notation is used. Single characters are always placed
%----in []s to disable any special meanings (for uniformity this is done to
%----all characters, not only those with special meanings).

%----These are tokens that appear in the syntax rules above. No rules
%----defined here because they appear explicitly in the syntax rules,
%----except that <vline>, <star>, <plus> denote "|", "*", "+", respectively.
%----Keywords:    fof cnf thf tff include
%----Punctuation: ( ) , . [ ] :
%----Operators:   ! ? ~ & | <=> => <= <~> ~| ~& * +
%----Predicates:  = != $true $false

%----For lex/yacc there cannot be spaces on either side of the | here
<comment>            ::- <comment_line>|<comment_block>
<comment_line>       ::- [%]<printable_char>*
<comment_block>      ::: [/][*]<not_star_slash>[*][*]*[/]
<not_star_slash>     ::: ([^*]*[*][*]*[^/*])*[^*]*
%----Defined comments are a convention used for annotations that are used as
%----additional input for systems. They look like comments, but start with %$
%----or /*$. A wily user of the syntax can notice the $ and extract information
%----from the "comment" and pass that on as input to the system. They are
%----analogous to pragmas in programming languages. To extract these separately
%----from regular comments, the rules are:
%----  <defined_comment>    ::- <def_comment_line>|<def_comment_block>
%----  <def_comment_line>   ::: [%]<dollar><printable_char>*
%----  <def_comment_block>  ::: [/][*]<dollar><not_star_slash>[*][*]*[/]
%----A string that matches both <defined_comment> and <comment> should be
%----recognized as <defined_comment>, so put these before <comment>.
%----Defined comments that are in use include:
%----    TO BE ANNOUNCED
%----System comments are a convention used for annotations that may used as
%----additional input to a specific system. They look like comments, but start
%----with %$$ or /*$$. A wily user of the syntax can notice the $$ and extract
%----information from the "comment" and pass that on as input to the system.
%----The specific system for which the information is intended should be
%----identified after the $$, e.g., /*$$Otter 3.3: Demodulator */
%----To extract these separately from regular comments, the rules are:
%----  <system_comment>     ::- <sys_comment_line>|<sys_comment_block>
%----  <sys_comment_line>   ::: [%]<dollar><dollar><printable_char>*
%----  <sys_comment_block>  ::: [/][*]<dollar><dollar><not_star_slash>[*][*]*[/]
%----A string that matches both <system_comment> and <defined_comment> should
%----be recognized as <system_comment>, so put these before <defined_comment>.

<single_quoted>      ::- <single_quote><sq_char><sq_char>*<single_quote>
%----<single_quoted>s contain visible characters. \ is the escape character for
%----' and \, i.e., \' is not the end of the <single_quoted>.
%----The token does not include the outer quotes, e.g., 'cat' and cat are the
%----same. See <atomic_word> for information about stripping the quotes.

<distinct_object>    ::- <double_quote><do_char>*<double_quote>
%---Space and visible characters upto ~, except " and \
%----<distinct_object>s contain visible characters. \ is the escape character
%----for " and \, i.e., \" is not the end of the <distinct_object>.
%----<distinct_object>s are different from (but may be equal to) other tokens,
%----e.g., "cat" is different from 'cat' and cat. Distinct objects are always
%----interpreted as themselves, so if they are different they are unequal,
%----e.g., "Apple" != "Microsoft" is implicit.

<dollar_word>        ::- <dollar><lower_word>
<dollar_dollar_word> ::- <dollar><dollar><lower_word>
<upper_word>         ::- <upper_alpha><alpha_numeric>*
<lower_word>         ::- <lower_alpha><alpha_numeric>*

%----Tokens used in syntax, and cannot be character classes
<vline>              ::- [|]
<star>               ::- [*]
<plus>               ::- [+]
<arrow>              ::- [>]
<less_sign>          ::- [<]

%----Numbers. Signs are made part of the same token here.
<real>               ::- (<signed_real>|<unsigned_real>)
<signed_real>        ::- <sign><unsigned_real>
<unsigned_real>      ::- (<decimal_fraction>|<decimal_exponent>)
<rational>           ::- (<signed_rational>|<unsigned_rational>)
<signed_rational>    ::- <sign><unsigned_rational>
<unsigned_rational>  ::- <decimal><slash><positive_decimal>
<integer>            ::- (<signed_integer>|<unsigned_integer>)
<signed_integer>     ::- <sign><unsigned_integer>
<unsigned_integer>   ::- <decimal>
<decimal>            ::- (<zero_numeric>|<positive_decimal>)
<positive_decimal>   ::- <non_zero_numeric><numeric>*
<decimal_exponent>   ::- (<decimal>|<decimal_fraction>)<exponent><integer>
<decimal_fraction>   ::- <decimal><dot_decimal>
<dot_decimal>        ::- <dot><numeric><numeric>*

%----Character classes
<percentage_sign>    ::: [%]
<double_quote>       ::: ["]
<do_char>            ::: ([\40-\41\43-\133\135-\176]|[\\]["\\])
<single_quote>       ::: [']
%---Space and visible characters upto ~, except ' and \
<sq_char>            ::: ([\40-\46\50-\133\135-\176]|[\\]['\\])
<sign>               ::: [+-]
<dot>                ::: [.]
<exponent>           ::: [Ee]
<slash>              ::: [/]
<zero_numeric>       ::: [0]
<non_zero_numeric>   ::: [1-9]
<numeric>            ::: [0-9]
<lower_alpha>        ::: [a-z]
<upper_alpha>        ::: [A-Z]
<alpha_numeric>      ::: (<lower_alpha>|<upper_alpha>|<numeric>|[_])
<dollar>             ::: [$]
<printable_char>     ::: .
%----<printable_char> is any printable ASCII character, codes 32 (space) to 126
%----(tilde). <printable_char> does not include tabs, newlines, bells, etc. The
%----use of . does not not exclude tab, so this is a bit loose.
<viewable_char>      ::: [.\n]
%----Top of Page---------------------------------------------------------------