v1.3.0
Breaking
Binders now scope over a single
<thf_unit_formula>, as the TPTP BNF prescribes. A binder body is an atom, a variable, a parenthesised formula, another binder, a~-prefixed unit formula or an infix (in)equation; an application chain or a binary connective that follows the body belongs to the enclosing formula:^ [X: $i] : f @ gnow reads( ^ [X: $i] : f ) @ g(the BNF states this case explicitly), and! [X: $o] : $false => pnow reads( ! [X: $o] : $false ) => p.- Formulas that relied on the previous greedy reading must parenthesise their
body:
! [X: $i] : ( p @ X ).
This fixes the family of
Cannot unify …type errors on TPTP problems that pass an unparenthesised binder as an argument, e.g.SET640^3'scartesian_product @ ^ [X: $i] : $true @ ^ [X: $i] : $true, and lets a binder body contain an equation (^ [X: $i] : ( p @ X ) = ( q @ X )).Unparsing already brackets binder bodies, so output of
ShotDs.Parser.unparse/1andShotDs.Tptp.unparse_problem/1is unaffected and still round-trips.Juxtaposition of a quantifier and its predicate (
! pfor∀ p) is no longer accepted; use the application form!! @ p.
Fixed
TH1 type arguments are now recognised when written as
<single_quoted>words, matching the other type-parsing sites. Problems whose type names are quoted throughout (e.g. everything includingAxioms/MAT001^0.ax) previously failed withCannot unify strict function types of different arities.ShotDs.Parser.unparse/1no longer drops the name of a bound variable that is passed as an argument. Such an argument is stored η-expanded, and collapsing the expansion left the head's de Bruijn index pointing past the enclosing scope ((cp @ @ X2)instead of(cp @ X1 @ X2)).ShotDs.Parser.unparse_type/1renders a mapping type into a user-declared base type as$int > ptinstead ofpt @ $int. Mapping types and type applications share one representation, so the type-application form is now used only for names declared with a type-constructor kind;ShotDs.Tptpregisters them from the problem's type declarations while unparsing, andShotDs.Parser.with_type_constructors/2exposes this for direct callers.TPTP's arithmetic constants (
$less,$lesseq,$greater,$greatereq,$sum,$difference,$product,$quotient,$quotient_e/_t/_f,$remainder_e/_t/_f,$uminus,$floor,$ceiling,$truncate,$round,$is_int,$is_rat,$to_int,$to_rat,$to_real) are ad-hoc polymorphic in the numeric sort instead of being fixed to one sort per problem, so a formula may compare$ints and$reals.