%----v5.5.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> -1- new 3 Tuesday, May 28, 2013 12:59 AM %----... 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 -2- new 3 Tuesday, May 28, 2013 12:59 AM %----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> -3- new 3 Tuesday, May 28, 2013 12:59 AM %----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> -4- new 3 Tuesday, May 28, 2013 12:59 AM <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_biding> 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_binding> | <tff_let_term_binding> <tff_let_term_binding> ::= <term> = <term> | (<tff_let_term_binding>) <tff_let_formula_defn> ::= ! [<tff_variable_list>] : <tff_let_formula_binding> | <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> | -5- new 3 Tuesday, May 28, 2013 12:59 AM <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> | -6- new 3 Tuesday, May 28, 2013 12:59 AM % <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 -7- new 3 Tuesday, May 28, 2013 12:59 AM <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 arguments are pairwise !=. It is part %----of the TFF syntax. <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> -8- new 3 Tuesday, May 28, 2013 12:59 AM <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>) -9- new 3 Tuesday, May 28, 2013 12:59 AM <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>) -10- new 3 Tuesday, May 28, 2013 12:59 AM %----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 -11- new 3 Tuesday, May 28, 2013 12:59 AM %----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. -12- new 3 Tuesday, May 28, 2013 12:59 AM <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--------------------------------------------------------------- -13-