There are too many ways to do trivial things

Stephan Schulz
TU München

Due to its heritage from Prolog, the TPTP syntax often is unnecessary general and hence complex. Allowing many different variants for semantically equivalent constructs is neither user-friendly, nor developer-friendly.

From a user perspective, there is more language to learn. Unless options add real expressiveness, there is no value in adding or maintaining them.
From a developer perspective, any possible alternative complicates the parser and internal processing of the language. Each possible path through the grammar also adds more ways for things to go wrong and increases the number of examples needed for decent test coverage.

There are currently constructs in the TPTP language that are not used in any TPTP problem, and quite probably not in any problem ever written in the TPTP language. Time spend to properly implement features that are never used is (rightly) perceived as wasted. As a consequence, there is a strong pressure to just implement and test the commonly used features. This leads to mutually incompatible language dialects. I'm not certain that there is a single conforming implementation of the language available.

One current example of unnecessary complication in the syntax is in the include statement or, more precisely, the file name syntax:

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

I can conceive no reason why a file should ever be named by a lower_word. Yes, some file names are lower words, but most are not. Any file name not local to the current directory is not a lower word. Any file name that can be represented as a lower_word can be trivially represented as a single-quoted (or doubly quoted, but only one alternative) string. No problem in the TPTP uses a lower_word as a file name in an include statement.

I would like to see the language pruned back to syntactic features that are actually used or for which a concrete case for added value can be made.

In order to be able to test each language feature in a systematic way, there should be a standard test set that exercises that feature.

As a matter of policy, I would suggest a process where TPTP language features can be formally challenged an unnecessary, and where anybody who makes a case to keep a given feature that is not currently used in TPTP has to submit a simple, non-contrived example to TPTP that uses that feature. A reasonable set of such problems might be organized in a TSC (TPTP Syntax Check) TPTP domain. To encourage support of the standard, TSC could even become a CASC category.