A Survey of Languages for Formalizing Mathematics
aa r X i v : . [ c s . L O ] M a y A Survey of Languagesfor Formalizing Mathematics
Cezary Kaliszyk ⋆ [0000 − − − and Florian Rabe ⋆⋆ [0000 − − − Universities of Innsbruck resp. Erlangen-Nürnberg
Abstract.
In order to work with mathematical content in computer sys-tems, it is necessary to represent it in formal languages. Ideally, these aresupported by tools that verify the correctness of the content, allow com-puting with it, and produce human-readable documents. These goals arechallenging to combine and state-of-the-art tools typically have to makedifficult compromises.In this paper we discuss languages that have been created for this pur-pose, including logical languages of proof assistants and other formalsystems, semi-formal languages, intermediate languages for exchangingmathematical knowledge, and language frameworks that allow buildingcustomized languages.We evaluate their advantages based on our experience in designing andapplying languages and tools for formalizing mathematics. We reach theconclusion that no existing language is truly good enough yet and deriveideas for possible future improvements.
Today’s formal systems can verify advanced theorems in mathematics [Hal14],such as the Kepler conjecture [Hal12] or the Feit–Thompson theorem [GAA + + formal languagesfor mathematical content that define syntax and semantics and offer strong au-tomation support. However, non-trivial and expensive transformation steps areneeded to formalize human-near natural language texts in them.This is in contrast to standard approaches to writing mathematics or specify-ing computer systems, which use natural language with interspersed syntacticallyunrestricted formulas, e.g., as written in L A TEX. While interpreting this naturallanguage is very difficult for computers (arguably AI-complete), it is extremelyeffective for humans in a way that formal languages have so far not been able ⋆ Supported by ERC starting grant no. 714034
SMART ⋆⋆ Supported by DFG grant RA-1872/3-1 OAF and EU grant Horizon 2020 ERI 676541OpenDreamKit. o capture. In fact, in 2007, Wiedijk claimed [Wie07], citing four representativestatements, that no existing formal system was sufficient to naturally expressbasic mathematical content. Despite the progress made since then, his critiquestill applies.We give an introduction to the objectives and main approaches in Section 2.Then Sections 3 and 4 describe the main approaches: formal system and in-termediate languages in more detail. Sections 5 and 6 describe closely relatedorthogonal aspects: language frameworks and interchange libraries. We evaluateour findings and conclude in Section 7.
Thus, a big picture goal of the field is a tighter integration of (i) natural lan-guage mathematical content such as textbooks or software specifications, and(ii) formalization of such content in logics and theorem proving systems. We canidentify the following overarching objectives:
A universal formal language for mathematical content that supports complexstructuring mechanisms
We want a language that combines the universality ofnatural mathematical languages with the automation support of formal logicsand programming languages. It should be closer to mathematics than these for-mal languages in regards to abstract syntax, notations, and type system. Thisis critical not only for generality but also to appeal to mathematicians at all be-cause, as Wiedijk observes, most mathematicians do not like to read (or write)code [Wie07]. On the other hand, it should be fully formal including automa-tion support for type, module, and proof systems of formal languages that haveproved critical for large scale applications.
A comprehensive standard library of mathematical concepts
The language mustallow for building a standard library of mathematical concepts. In order to allowfor semantics-aware machine support, it should be more formal than existinginformal libraries such as induced by Wikipedia or PlanetMath by includingformal types, notations, and properties. On the other hand, in order to achievegenerality and support interoperability, it should not be committed to a partic-ular logic like all the major formal libraries are. This combination of advantageswould allow it to serve as a standard library, i.e., a central community resourceto be used, e.g., to cross-link between existing libraries in a star-shaped networkor to provide a basis for projects like FAbstracts [Hal17].
Practical workflows that integrate natural and formal languages
Such a languageand standard library would enable substantially better tool support for workingresearchers in mathematical sciences: Being structurally similar to both naturaland formal languages, they could serve as an interface language for tools ofeither kind. This would allow enriching existing workflows such as L A TEX-based2uthoring or proof-assistant–based verification. For example, researchers couldeasily formalize conjectures and their proof outlines in a general language as afirst and cheap formalization step, before or instead of a full verification of theproof. This would avoid hindering practicians as today’s all-or-nothing approachof formalization in proof assistants tends to do [KR16]. It is critical for successhere to retain existing workflows instead of trying to develop a single be-all-end-all tool that no one would adopt. Therefore, any major project in this directionmust aim at developing concrete improvements to the current ecosystem.
The most successful formal languages for mathematical content have been de-veloped in the areas of formal logic where they occur most prominently as theinput languages of proof assistants as well as in computer algebra where theyoccur as programming languages fitted to mathematical algorithms. These com-bine formal foundations with complex structuring mechanisms, especially type,module, proof, and computation systems, which have proved critical to achieveefficient large scale tool support. Importantly, these fix not only the syntax butalso the semantics of, e.g., proofs and computations On the contrary, in naturallanguage, these are not spelled out at all, let alone explicated as a primitive fea-ture — instead, they are emergent features driven by conventions and flexiblyadaptable to different contexts. Consequently, formalization is usually a non-structure-preserving transformation that is often prohibitively expensive andcreates an entry barrier for casual users. For example, the mathematician KevinBuzzard admonishes computer scientists to build more human-near languages“so users can at least read sentences they understand and try to learn to writethese sentences”.Between the extremes of natural and formal languages, a variety of inter-mediate languages make different trade-offs aiming at combining the universalapplicability of natural language with the advantages of formal semantics. Acentral observation is that – existing intermediate languages apply only the formal syntax and (to varyingdegrees) semantics of formal languages but not their complex structuringmechanisms, and – this limitation is not necessarily an inherent feature of the approach butrather a frontier of research.The following table summarizes the resulting trichotomy and shows how eachkind of language satisfies only two out of three essential requirements:language properties natural intermediate formalformal syntax and semantics – + +complex structuring + – +universal applicability + + –In the subsequent sections, we discuss the state of the art for these languagesin more detail. 3 Formal Languages
Formal languages use a wide variety of foundations and complex structuringmechanisms. This unfortunately means that it is rare for two tools to be compat-ible with each other. Additionally, all are quite removed from natural language.In the sequel, we discuss the most important complex structuring features.
Many formal systems use what we call hard type systems, which assign a uniquetype to each object and are thus easiest to automate. Systems derived fromMartin-Löf type theory [ML74] or the calculus of constructions [CH88] usuallyuse the proofs-as-programs correspondence (Curry-Howard [CF58,How80]) thatrepresents mathematical properties as types and proofs as data. These includeAgda [Nor05], Coq [Coq15], Lean [dKA + + semi-soft typesystems if a hard type system is extended with variants of subtyping. For exam-ple, PVS [ORS92] uses predicate subtypes, Lean [dKA +
15] and Nurpl [CAB + ∀ x : N .P ( x ) ) or the logicalsystem (e.g., ∀ x.x ∈ N ⇒ P ( x ) ). Problematically, this choice usually has far-reaching consequences, e.g., the type system may be decidable but the logicsystem undecidable. But from the perspective of mathematics this distinctionis artificial, and the fact that the two resulting representations may be entirelyincompatible down the road is very awkward.These problems are avoided in untyped languages. ACL2 [KMM00] is a first-order logic on top of the untyped λ -calculus of Lisp that strongly emphasizescomputation. Untyped set theory is used in Isabelle/ZF [PC93], Metamath[Meg07], and the B method [Abr96]. Untyped languages are also common invirtually all computer algebra systems, such as Mathematica [Wol12] or Sage-Math [S + soft type systems if unary predicates on the untyped objectsmimic types and the type system is an emergent feature of the logical system.4hese are used most prominently in Mizar [TB85] among proof assistants andGAP [Lin07] among computer algebra systems. Both use the types-as-predicatesapproach, where the semantics of a type is given by a unary predicate rangingover untyped objects. Both allow declaring functions and dependent types (i.e.,predicates n + 1 arguments that return a unary predicate after fixing the first n arguments) that have type constraints on the arguments. Soft type systemsare generally hardest to automate because type-checking is reduced to undecid-able theorem proving. Here Mizar leverages theorem proving: the type checkeris guided by user-stated typing rules (called registrations), which are speciallymarked theorems about typing properties. GAP leverages computation: the typ-ing predicates must be computable properties, which are computed and cachedat run-time for every object.Thus, soft type systems are heuristic, which makes implementations moredifficult for the developer and their behavior less predictable for the user. Butthey are the most human-friendly. A combination of hard and soft type systems,where advanced hard type systems are emergent features built systematically ontop of a soft one, could potentially model mathematical content best but has sofar received much less systematic attention than the above approaches. But astheorem proving technology becomes more routine, they become more and moreattractive.An example soft type system has been recently developed on top of a hard-typed Isabelle for the Isabelle/Mizar object logic [KP19a], which expresses thelargest softly typed proof library in a logical framework. As part of this research,the type system of Mizar has been formalized including its intersection type con-structions, various ways to express set-theoretic structures, and declarative prooftranslations [KP19b] have been investigated. Furthermore, a common founda-tion for proofs that allows practically combining results between HOL and settheory has been developed [BKP19]. A key use of modules is to represent structures (also called records or theories);here the abstract definition (e.g., “group”) is represented as a module, and con-crete models (e.g., individual groups) are represented as instances of the module.The used module systems vary widely but roughly fall into the following groups.Firstly, ML-inspired external module systems use a two-layer language wherethe module language is external to the logical language. These allow for inher-itance, refinement, and instantiation (e.g., Coq modules, Isabelle locales, PVStheories, SageMath categories, Axiom categories) as well as more advanced struc-turing such as parametric modules (e.g., PVS), module expressions (e.g., Isabellelocales, Axiom joins), or morphisms between modules (Isabelle, IMPS). Hardmodule systems differ greatly from natural language where no two-layer lan-guage is fixed.Secondly, internal module systems use record types to mimic modular struc-ture inside the type system. This is possible in all systems that support record5ypes (e.g., Agda, Coq, Isabelle, Lean, PVS); Mizar’s structures behave simi-larly. Soft modules are more flexible and thus similar to natural language, butthe lack of a concise module system makes modular reasoning like inheritanceand refinement more difficult. For example, soft module systems must manu-ally employ extra-logical conventions (e.g., [GGMR09]), and combining modulesbuilt with different conventions quickly becomes impractical. This is even worsein the common case where both hard and soft module systems are present inparallel (we have initiated work in this direction in [MRK18]).Both of the above can be seen as hard module systems in the sense that amodule encapsulates a fixed set of declarations that induce selectors that canbe applied to the module’s instances. A third group, which we call soft modulesystems is somewhat hypothetical as it is used much less widely. Here, in analogyto soft tying, modules are treated as unary predicates that range over objects.Inheritance then becomes a special case of implication. This idea is used inthe GAP module system, whose soft types (called properties) and soft modules(called categories) are treated very similarly: they are jointly filters, and therun-time system tracks which object satisfies which filters. The main differencebetween them is that categories can have constructors and thus allow for filtersthat are satisfied by construction.Finally, since module systems have mostly been designed as extensions ofexisting logical languages, both hard and soft module systems fail to capture anumber of essential features of natural mathematical language: the identificationof isomorphic instances of the same module; the seamless extension of operationsacross substructures and quotient structures (e.g., + is first defined on N , thenextended to Z ); the flexibility of presence and order of fields in a structure (e.g., ( Z , + , ∗ ) and ( Z , + , , − , ∗ , should be the same ring); the context-sensitivemeaning of structures (e.g., Z should be a ring or a total order, depending on thecontext); and in many systems also the implicit application of forgetful functors(e.g., a group is not automatically also a monoid). Formal languages shine when using logics implemented in proof assistants to findand check proofs automatically.
Tactic-based proof systems (e.g., HOL Light) areoptimized for efficiency of proof checking but have an imperative flavor that isvery different from natural mathematical language.
Declarative proof systems(e.g. Mizar, Isabelle/Isar) were designed to be closer to natural language.While many current tools support declarative proofs using quite similar lan-guages, all of these are intertwined with the respective logic and therefore notimmediately reusable as a universally applicable declarative proof language. Inparticular, the expressivity of these languages is limited by the strength of theunderlying logic, i.e., they can only express the kind of proof steps that canbe potentially verified by the tool. Declarative proof languages are conceptuallyclose to natural mathematics but technically tied to specific logics. We discusslogical languages in more detail in section 5.6n computer algebra systems no formal logics are implied and automatedreasoning is restricted to computable properties. Additionally, these systemscan capture logical properties by user declaration: for example, most systems’libraries distinguish between groups and commutative groups and allow users toconstruct a group as commutative even if that property is not proved.
The second major application of formal languages stems from computer algebrasystems, which use mathematics-customized variants of general purpose pro-gramming languages for efficient computation.Even though mathematics uses mostly pure functions, most systems arebased on Turing-complete imperative programming, mostly to reuse existing userknowledge and fast implementations. It is common to use the same language forpure mathematical algorithms and interspersed imperative meta-operations likeI/O, logging, memoization, or calling external tools (in particular in SageMath).Proof assistants take a much more restricted approach to integrate pure com-putations with a logic. Three main approaches exist. Firstly, normalization inthe type theory, in particular β -reduction is a primitive form of computation. Itbecomes much stronger when combined with (co)inductive types and recursion,and these are primitive features in most complex type theories like Coq. Systemsthen usually include heuristic termination criteria to check the soundness of thefunctions, which leads to a trade-off between logical and Turing-completeness.Secondly, certain theorems such as Horn formulas about equality can be inter-preted as conditional rewrite rules. Typically, systems require the user to choosewhich theorems to use and then exhaustively rewrite expressions with them.This is much slower but allows for a much simpler language as computation isrelegated to the meta-level. This is the main method used in systems withoutprimitive (co)inductive types such as Isabelle. Thirdly, computation can be sup-plied by external tools or special kernel modules. This computation can be apart of the, consequently rather big, trusted code base, such as in PVS decisionprocedures, the usage of SAT solvers is Mizar [Nau14]. This is also the case inTheorema: As the proof assistant is written in the Mathematica computer al-gebra system, it is in principle possible to use most Mathematica’s algorithmsinside Theorema [Win14]. In some cases, a trade-off is possible where computa-tions are run externally and their results are efficiently verified by the prover. Intermediate languages try to capture the advantages of natural languages ina formal language. There is a rather diverse set of such approaches, which wedescribe in groups below. However, we can identify some general effects thatmotivate the design of many intermediate languages.Firstly, an intermediate language can already provide sufficient automationsupport for some tasks. Thus, it can serve as a more natural and easier-to-use7 ormality f un c t i o n a li t y I n t e r a c t i v e D o c u m e n t s S e m a n t i c S e a r c h T y p e c h e c k i n g V e r i f i c a t i o n formality l a n g u ag e s upp o r t Fig. 1.
Functionality for intermediate languages (left)market gap for stepwise formalization support (right) target language for (partial) formalization if the task at hand is supported. Forexample, search, interactive documents, or dependency management can be real-ized well in some intermediate languages and even benefit from structural similar-ity to the human-near natural language formulation. The main counter-examplesare verification and computation, which requires a lot more formalization. Thisis indicated in Figure 1 (left).Secondly, an intermediate language can serve as an interface between human-near natural language and a verification- or computation-oriented formal lan-guage. This enables stepwise formalization and thus a smoother transition fromthe informal to the formal realm. It may also allow for a separation of concernswhere a domain experts transform content from informal to intermediate in afirst step and a formalization transforms from intermediate to formal in a secondstep. The relative lack of highly successful approaches in this style is indicatedin Figure 1 (right).Thirdly, the intermediate representation is often not or only barely commit-ted to a particular formal language (e.g., a particular type system, module sys-tem, proof system or computation system). During stepwise formalization, thismeans that the first step only needs to be done once and can then be reused fordifferent second steps targeting different formal languages. Expanding on this,we see that an intermediate language can provide an interoperability layer be-tween formal languages. That can help with the notorious lack of interoperabilitybetween formal systems (see also Section 6).
These approaches combine formal grammars for fragments of natural languagewith formal languages for formulas. Their goal is to make the surface syntax of aformal language as close to traditional mathematics as possible while retaininga formal grammar that allows for automated parsing. While the languages often8ook similar to some semi-formal languages discussed below, we classify themdifferently because they use a formal logic-near language in their kernel.This method is applied in MathLang [KW08,KWZB14], MathNat [Hum12],in [KN12] within the FMathL project, and Naproche [CFK + ∼ theorems in the biggest systems)are developed and shared in vibrant communities, none of the controlled natu-ral language systems provides a substantial library. This is a hen-egg problemsince large libraries often result from the practical necessities caused by verifi-cation and computation. A critical limiting factor of existing controlled naturallanguages is the lack of scalable automation support and large libraries. These approaches aim at combining unrestricted natural mathematical languageand formal language in the same document. Contrary to the controlled naturallanguage approaches discussed above, the interpretation of the natural languageparts remains AI-complete.
Flexiformal systems use informal and formal language as alternatives, i.e.,content may be written informally or formally. Thus, not all mathematical con-tent is formalized, and all tool support must degrade gracefully when informaland thus uninterpretable content is encountered. The sTeX system [Koh08] is aL A TEX package for annotating informal mathematical texts with its formal mean-ing, which then allows for writing (parts of) formulas in formal logical syntax.In addition to pdf, sTeX documents can be processed into
OMDoc documents[Koh06], which makes them available for further machine processing. sTeX pro-vides no type system and only a very simple hard module system. It has beenused by the developer to write his introductory computer science lecture notes.
Literate programming [Knu84] and approaches inspired by it allow fornatural and formal language to appear in parallel. Here, content is describedtwice: the formal version defines the semantics, and the informal version providesdocumentation. Contrary to the other approaches mentioned here, this is not athird language in between formal and natural, but a combination of the two.Several formal systems provide mature support for writing content in literateprogramming style such as Agda, Isabelle (see [Wen11]), and Axiom.
Discourse representation languages [KR93] perform an analysis of thelanguage used in written mathematics and design a fixed set of disambiguation9onventions. Ganesalingam [Gan13] proposes a system of types that togetherwith a parsing procedure and the set of disambiguation conventions could beused to parse non-foundational mathematics. Apart from the foundational issues,the approach also has a problem with adaptivity of mathematical texts.
These approaches apply the general principles of formal languages while avoidinga commitment to a particular logic or implementation. A major goal is systeminteroperability.
Standardized representation languages have been developed in the areaof knowledge management such as
OpenMath [BCC + MathML [ABC + OMDoc [Koh06]. These prioritize standardizing the syntax us-ing standard machine-friendly representation formats such as XML (where theformal structure of objects is explicit). They do not specify user-friendly surfacesyntaxes (where the formal structure would have to be inferred through complexparsing and disambiguation) or rigorous semantics. This allows their use as in-terchange languages (e.g., in the SCIEnce [HR09] and OpenDreamKit [DIK + interchange languages mostly developedfor theorem provers. They are restricted to small families of logical languagesused in theorem provers. Thus, they are more widely applicable than individuallogical languages but less widely than the truly universal standard representationlanguages. The TPTP [Sut09] family of languages has played a major role in thecommunity: it serves the role of a common language for automated theoremprover inputs and outputs. TPTP was originally restricted to first-order logics,and a few extensions exist [BRS08,SSCB12], which co-evolve with the availabletheorem provers, thus offering the possibility of problem exchange also betweenformal proof systems. OpenTheory [Hur09] is restricted to the HOL-based proofassistants. It offers some support for abstracting from the systems’ idiosyncrasiesin order to increase portability, and some HOL theories have been manuallyrefactored to make use of this abstraction. The ISO-standardized Common Logic[edi07] has a broader ambition, aiming at interchanging between any knowledge-based systems. But its applicability to mathematics is limited by its focus onfirst-order logic and a lack of integration with mathematical software.Overall, interchange languages focus mostly on a universal formal syntax while sacrificing a universal semantics or restrict attention to small families oflanguages. Neither provides strong support for type/module/proof/computationsystems that would be critical to capture the complexity of large scale formal li-braries. A partial exception is the second author’s Mmt system, which combinesaspects of standard languages [DIK + +
17] and prover interchange lan-guages [BRS08,HR15,KRS16] with hard type and module systems [RK13]. TheOAF project [KR16,KR20] used
Mmt to represent large libraries of proof assis-tants in a standard representation language, including those of Mizar in [IKR11],10OL Light in [KR14], PVS in [KMOR17] (including the NASA library), Coq in[MRS19] (including all available libraries), and Isabelle in [KRW20] (includingthe Archive of Formal Proofs).
Language frameworks are formal languages in which the syntax and semanticsof other languages can be represented. They are superficially related to parserframeworks but much stronger because they (i) allow specifying not only thesyntax but also the semantics of a language, (ii) often offer strong support forcontext-sensitivity, which is critical in mathematics.Logical frameworks are language frameworks for building formal language.Examples are Isabelle [Pau94], Dedukti [BCH12], λ Prolog [MN86], or the LF[HHP93] family including Twelf [PS99] and others. Frameworks also exist forbuilding controlled natural languages such as GF [Ran11].Contrary to the approaches discussed above, these frameworks do not inthemselves provide languages for formalizing mathematics. But they are worthdiscussing in this context for two reasons: Firstly, they allow the rapid proto-typing of implementations, which speeds up the feedback loop between languagedesign and applications. Thus, users can experiment with new languages andconduct large case studies in parallel. Secondly, they allow developing scalableapplications language-independently such that they are immediately applicablefor any language defined in the framework. That is important because evaluat-ing formal languages often requires building (or trying to build) large libraries inthem. Such applications include at least parsing and type-checking but can alsoinclude meta-reasoning (e.g., Twelf), interactive theorem proving (e.g., Isabelle),or language translation (e.g., GF).Despite many successes in representing logical languages in logical frame-works (e.g., [CHK + Mmt [Rab17,Rab18] allow users to flexibly change criticalalgorithms whenever a concrete language definition needs it. That makes themmore promising for representing languages designed for mathematical content(and can even allow sharing some functionality across incompatible foundations).
Mmt [Rab13,RK13] is a logic-independent representation and managementsystem for formal logical content that uses logical frameworks to provide a rigor-ous semantics for
OMDoc and
OpenMath . It manages all aspects of languagedesign in a coherent framework including language definition, rapid prototyp-ing of tools, and library development. Fully parametric in the choice of formalsystem, it maximizes the reuse of concepts, formalizations, and tool support. It11ubsumes in particular logical frameworks such as the LF family [MR19]. TheLATIN project [CHK +
11] used an
Mmt precursor language based on the Twelfmodule system [RS09] to build a library of common logics of symbolic softwaresystems and proof checkers. It contains close to 1000 modules (theories andmorphisms between them), which can be imported into
Mmt .[KRSS20] makes the first steps towards combining the advantages of
Mmt and ELPI. [KS19] uses
Mmt to extend LF-like logical frameworks with thenatural language framework GF.
The quest for the best formal language for mathematics is likely to never-ending.Therefore, it is important to investigate how to combine the existing libraries offormalized content. Due to major incompatibilities between the various formalsystems, this is an extremely difficult problem, and it would go beyond the scopeof this paper to discuss approaches in detail. But we want to mention the ideaof interchange libraries because we consider it to be one of the most promisingideas.An interchange library I is a formalization of mathematics written in an in-termediate language with the goal of serving as an interoperability layer betweenformal systems. The main idea is that all translations from source system S totarget system T are split into two steps S → I and I → T .Both steps have characteristic difficulties. The step S → I is usually a partialtranslation because every formal systems uses idiosyncratic features that cannotbe represented in I and optimizations for verification/computation that neednot be represented in I . The step I → T tends to be easier, but there is a trickytrade-off in the design of I : the less I commits to a particular formal system, themore systems T can be handled but the more difficult the individual translations I → T become. In practice, a further major logistic problem is that I and thetranslations via it needs to be built and maintained, which is even harder toorganize and fund than for the systems S and T themselves.The standard content dictionaries written in OpenMath [BCC +
04] were thefirst concerted effort to build an interchange library. dictionaries (includingcontributed ones) declaring symbols are maintained by the OpenMath So-ciety. These focus on declaring names for mathematical symbols and describingtheir semantics verbally and with formal axioms. However, the approach wasnot widely adopted as little tool support existed for OpenMath itself and forOpenMath-based interoperability. Individual formal systems were also less ableto export/import their objects at all.Recently, the idea was picked up again in the OpenDreamKit project. Ituses
Mmt (whose language of theories and expressions essentially subsumesOpenMath CDs and objects) to write a formal interchange library (dubbed MitMfor Math-in-the-middle) [DIK + +
17] and mathematicaldatabases [WKR17,BKR19].A complementary approach is SMGloM [GIJ + S → I and I → T , the concept of alignments was developed [KKMR16]. An alignmentbetween two symbols c and c ′ in different libraries captures that translationsshould try to translate objects with c to objects with head d . Both exact manualefforts [MRLR17] and machine learning–based heuristic approaches were usedto find alignments across formal libraries. The latter includes alignment from sixproof assistants [GK19], showing that such alignments allow both conjecturingand more powerful automation [GK15]. The same approach has been used toobtain alignments between informal and formal libraries, which can be used toautomatically formalize parts of mathematical texts, both statistically [KUV17]and using deep learning techniques [WKU18]. Similarly, [GC14] automaticallyobtains alignments between informal libraries. We have presented a survey of languages for formalizing mathematics. The var-ious languages have been designed and implemented for different purposes andhave different features, and their many distinguishing features give them char-acteristic advantages and disadvantages. Natural language that mathematiciansare used to lacks formal semantics (and in many cases even formal syntax). Butfully formal languages are still very far from natural language. And existing in-termediate languages lack complex structuring features and large libraries andscalable tools that would make them directly usable for formalization.We expect that future research in the domain must continue to experimentwith language development aiming at the formal representation of syntax andsemantics while preserving natural readability and extensibility and large-scalestructuring features. The use of language frameworks will be helpful to rapidlyexperiment with these novel ideas. We see a lot of potential in the developmentof a new intermediate language along those lines that could enable partial andstepwise formalization as well as provide an interoperability layer for formallanguages. Concretely, we expect this future language to feature at least a com-bination of soft type and module systems with rigorous development of theirhard analogues as emergent features. 13 eferences
ABC +
10. R. Ausbrooks, S. Buswell, D. Carlisle, G. Chavchanidze, S. Dalmas, S. De-vitt, A. Diaz, S. Dooley, R. Hunter, P. Ion, M. Kohlhase, A. Lazrek, P. Lib-brecht, B. Miller, R. Miner, C. Rowley, M. Sargent, B. Smith, N. Soif-fer, R. Sutor, and S. Watt. Mathematical Markup Language (MathML)Version 3.0. Technical report, World Wide Web Consortium, 2010. See .Abr96. J. Abrial.
The B-Book: Assigning Programs to Meanings . Cambridge Uni-versity Press, 1996.Art. R. Arthan. ProofPower. .ASTZ06. A. Asperti, C. Sacerdoti Coen, E. Tassi, and S. Zacchiroli. Crafting a ProofAssistant. In T. Altenkirch and C. McBride, editors,
TYPES , pages 18–32.Springer, 2006.BCC +
04. S. Buswell, O. Caprotti, D. Carlisle, M. Dewar, M. Gaetano, andM. Kohlhase. The Open Math Standard, Version 2.0. Technical report, TheOpen Math Society, 2004. See .BCH12. M. Boespflug, Q. Carbonneaux, and O. Hermant. The λΠ -calculus moduloas a universal proof language. In D. Pichardie and T. Weber, editors, Proceedings of PxTP2012: Proof Exchange for Theorem Proving , pages 28–43, 2012.BKP19. C. Brown, C. Kaliszyk, and K. Pąk. Higher-order Tarski Grothendieck as afoundation for formal proof. In John Harrison, John O’Leary, and AndrewTolmach, editors,
Interactive Theorem Proving , volume 141 of
LIPIcs , pages9:1–9:16, 2019.BKR19. K. Berčič, M. Kohlhase, and F. Rabe. Towards a Unified MathematicalData Infrastructure: Database and Interface Generation. In C. Kaliszyk,E. Brady, A. Kohlhase, and C. Sacerdoti Coen, editors,
Intelligent Com-puter Mathematics , pages 28–43. Springer, 2019.BRS08. C. Benzmüller, F. Rabe, and G. Sutcliffe. THF0 – The core of the TPTPLanguage for Higher-Order Logic. In A. Armando, P. Baumgartner, andG. Dowek, editors, , pages 491–506. Springer, 2008.CAB +
86. R. Constable, S. Allen, H. Bromley, W. Cleaveland, J. Cremer, R. Harper,D. Howe, T. Knoblock, N. Mendler, P. Panangaden, J. Sasaki, and S. Smith.
Implementing Mathematics with the Nuprl Development System . Prentice-Hall, 1986.CF58. H. Curry and R. Feys.
Combinatory Logic . North-Holland, Amsterdam,1958.CFK +
09. M. Cramer, B. Fisseni, P. Koepke, D. Kühlwein, B. Schröder, and J. Veld-man. The Naproche Project Controlled Natural Language Proof Checkingof Mathematical Texts. In N. Fuchs, editor,
Controlled Natural Language ,pages 170–186. Springer, 2009.CH88. T. Coquand and G. Huet. The Calculus of Constructions.
Information andComputation , 76(2/3):95–120, 1988.CHK +
11. M. Codescu, F. Horozal, M. Kohlhase, T. Mossakowski, and F. Rabe.Project Abstract: Logic Atlas and Integrator (LATIN). In J. Davenport,W. Farmer, F. Rabe, and J. Urban, editors,
Intelligent Computer Mathe-matics , pages 289–291. Springer, 2011. hu40. A. Church. A Formulation of the Simple Theory of Types. Journal ofSymbolic Logic , 5(1):56–68, 1940.Coq15. Coq Development Team. The Coq Proof Assistant: Reference Manual.Technical report, INRIA, 2015.DGST15. C. Dunchev, F. Guidi, C. Sacerdoti Coen, and E. Tassi. ELPI: Fast, Em-beddable, lambda-Prolog Interpreter. In M. Davis, A. Fehnker, A. McIver,and A. Voronkov, editors,
Logic for Programming, Artificial Intelligence,and Reasoning , pages 460–468, 2015.DIK +
16. P. Dehaye, M. Iancu, M. Kohlhase, A. Konovalov, S. Lelièvre, D. Müller,M. Pfeiffer, F. Rabe, N. Thiéry, and T. Wiesing. Interoperabilityin the OpenDreamKit Project: The Math-in-the-Middle Approach. InM. Kohlhase, L. de Moura, M. Johansson, B. Miller, and F. Tompa, ed-itors,
Intelligent Computer Mathematics , pages 117–131. Springer, 2016.dKA +
15. L. de Moura, S. Kong, J. Avigad, F. van Doorn, and J. von Raumer. TheLean Theorem Prover (System Description). In A. Felty and A. Middeldorp,editors,
Automated Deduction , pages 378–388. Springer, 2015.edi07. Common Logic editors. Common Logic (CL) — A framework for a familyof logic-based languages. Technical Report 24707, ISO/IEC, 2007.FGT93. W. Farmer, J. Guttman, and F. Thayer. IMPS: An Interactive Mathe-matical Proof System.
Journal of Automated Reasoning , 11(2):213–248,1993.GAA +
13. G. Gonthier, A. Asperti, J. Avigad, Y. Bertot, C. Cohen, F. Garillot, S. LeRoux, A. Mahboubi, R. O’Connor, S. Ould Biha, I. Pasca, L. Rideau,A. Solovyev, E. Tassi, and L. Théry. A machine-checked proof of the OddOrder Theorem. In S. Blazy, C. Paulin-Mohring, and D. Pichardie, editors,
Interactive Theorem Proving (ITP) , volume 7998 of
LNCS , pages 163–179.Springer, 2013.Gan13. M. Ganesalingam.
The Language of Mathematics. A Linguistic and Philo-sophical Investigation . Number 7805 in LNCS. Springer, 2013.GC14. D. Ginev and J. Corneli. NNexus reloaded. In S. Watt, J. Davenport,A. Sexton, P. Sojka, and J. Urban, editors,
Intelligent Computer Mathe-matics , pages 423–426. Springer, 2014.GGMR09. F. Garillot, G. Gonthier, A. Mahboubi, and L. Rideau. Packaging mathe-matical structures. In S. Berghofer, T. Nipkow, C. Urban, and M. Wenzel,editors,
Theorem Proving in Higher Order Logics , pages 327–342. Springer,2009.GIJ +
16. D. Ginev, M. Iancu, C. Jucovschi, A. Kohlhase, M. Kohlhase, A. Oripov,J. Schefter, W. Sperber, O. Teschke, and T. Wiesing. The SMGloM projectand system: Towards a terminology and ontology for mathematics. In G.-M.Greuel, T. Koch, P. Paule, and A.J. Sommese, editors,
Mathematical Soft-ware - ICMS 2016 - 5th International Conference, Berlin, Germany, July11-14, 2016, Proceedings , volume 9725 of
LNCS , pages 451–457. Springer,2016.GK15. T. Gauthier and C. Kaliszyk. Sharing HOL4 and HOL Light proof knowl-edge. In M. Davis, A. Fehnker, A. McIver, and A. Voronkov, editors, , volume 9450 of
LNCS , pages 372–386.Springer, 2015.GK19. T. Gauthier and C. Kaliszyk. Aligning concepts across proof assistantlibraries.
J. Symbolic Computation , 90:89–123, 2019. al12. T. Hales. Dense Sphere Packings: A Blueprint for Formal Proofs , volume400 of
London Mathematical Society Lecture Note Series . Cambridge Uni-versity Press, 2012.Hal14. T. Hales. Developments in formal proofs.
Séminaire Bourbaki , 1086, 2013–2014. abs/1408.6474.Hal17. T. Hales. The formal abstracts project, 2017. https://formalabstracts.github.io/ .Har96. J. Harrison. HOL Light: A Tutorial Introduction. In
Proceedings of the FirstInternational Conference on Formal Methods in Computer-Aided Design ,pages 265–269. Springer, 1996.HHP93. R. Harper, F. Honsell, and G. Plotkin. A framework for defining logics.
Journal of the Association for Computing Machinery , 40(1):143–184, 1993.HOL. HOL4 development team. https://hol-theorem-prover.org/ .How80. W. Howard. The formulas-as-types notion of construction. In
To H.B.Curry: Essays on Combinatory Logic, Lambda-Calculus and Formalism ,pages 479–490. Academic Press, 1980.HR09. P. Horn and D. Roozemond. OpenMath in SCIEnce: SCSCP and POP-CORN. In J. Carette, L. Dixon, C. Sacerdoti Coen, and S. Watt, editors,
Intelligent Computer Mathematics , pages 474–479. Springer, 2009.HR15. F. Horozal and F. Rabe. Formal Logic Definitions for Interchange Lan-guages. In M. Kerber, J. Carette, C. Kaliszyk, F. Rabe, and V. Sorge,editors,
Intelligent Computer Mathematics , pages 171–186. Springer, 2015.Hum12. M. Humayoun.
Developing System MathNat for Automatic Formalizationof Mathematical texts . PhD thesis, Université de Grenoble, 2012.Hur09. J. Hurd. OpenTheory: Package Management for Higher Order Logic The-ories. In G. Dos Reis and L. Théry, editors,
Programming Languages forMechanized Mathematics Systems , pages 31–37. ACM, 2009.IKR11. M. Iancu, M. Kohlhase, and F. Rabe. Translating the Mizar MathematicalLibrary into OMDoc format. Technical Report KWARC Report-01/11,Jacobs University Bremen, 2011.KAE +
14. G. Klein, J. Andronick, K. Elphinstone, T.C. Murray, T. Sewell, R. Kolan-ski, and G. Heiser. Comprehensive formal verification of an OS microkernel.
ACM Trans. Comput. Syst. , 32(1):2, 2014.KKMR16. C. Kaliszyk, M. Kohlhase, D. Müller, and F. Rabe. A Standard for Align-ing Mathematical Concepts. In A. Kohlhase, M. Kohlhase, P. Libbrecht,B. Miller, F. Tompa, A. Naummowicz, W. Neuper, P. Quaresma, andM. Suda, editors,
Work in Progress at CICM 2016 , pages 229–244. CEUR-WS.org, 2016.KMM00. M. Kaufmann, P. Manolios, and J Moore.
Computer-Aided Reasoning: AnApproach . Kluwer Academic Publishers, 2000.KMOR17. M. Kohlhase, D. Müller, S. Owre, and F. Rabe. Making PVS Accessibleto Generic Services by Interpretation in a Universal Format. In M. Ayala-Rincon and C. Munoz, editors,
Interactive Theorem Proving , pages 319–335.Springer, 2017.KMP +
17. M. Kohlhase, D. Müller, M. Pfeiffer, F. Rabe, N. Thiéry, V. Vasilyev, andT. Wiesing. Knowledge-Based Interoperability for Mathematical SoftwareSystems. In J. Blömer, I. Kotsireas, T. Kutsia, and D. Simos, editors,
Mathematical Aspects of Computer and Information Sciences , pages 195–210. Springer, 2017. N12. K. Kofler and A. Neumaier. Dyngenpar - a dynamic generalized parser forcommon mathematical language. In J. Jeuring, J. Campbell, J. Carette,G. Dos Reis, P. Sojka, M. Wenzel, and V. Sorge, editors,
Intelligent Com-puter Mathematics , volume 7362, pages 386–401. Springer, 2012.Knu84. D. Knuth. Literate programming.
The Computer Journal , 27(2):97–111,1984.Koh06. M. Kohlhase.
OMDoc: An Open Markup Format for Mathematical Docu-ments (Version 1.2) . Number 4180 in Lecture Notes in Artificial Intelli-gence. Springer, 2006.Koh08. M. Kohlhase. Using L A TEX as a Semantic Markup Format.
Mathematics inComputer Science , 2(2):279–304, 2008.KP19a. C. Kaliszyk and K. Pąk. Semantics of Mizar as an Isabelle object logic.
J.Autom. Reasoning , 63(3):557–595, 2019.KP19b. C. Kaliszyk and K. Pąk. Declarative proof translation (short paper). InJ. Harrison, J. O’Leary, and A. Tolmach, editors, , volume 141 of
LIPIcs ,pages 35:1–35:7, 2019.KR93. H. Kamp and U. Reyle.
From Discourse to Logic. Introduction to Mod-eltheoretic Semantics of Natural Language, Formal Logic and DiscourseRepresentation Theory , volume 42 of
Studies in Linguistics and Philoso-phy . Springer, 1993.KR14. C. Kaliszyk and F. Rabe. Towards Knowledge Management for HOL Light.In S. Watt, J. Davenport, A. Sexton, P. Sojka, and J. Urban, editors,
In-telligent Computer Mathematics , pages 357–372. Springer, 2014.KR16. M. Kohlhase and F. Rabe. QED Reloaded: Towards a Pluralistic FormalLibrary of Mathematical Knowledge.
Journal of Formalized Reasoning ,9(1):201–234, 2016.KR20. M. Kohlhase and F. Rabe. Experiences from Ex-porting Major Proof Assistant Libraries. see https://kwarc.info/people/frabe/Research/KR_oafexp_20.pdf , 2020.KRS16. C. Kaliszyk, F. Rabe, and G. Sutcliffe. TH1: The TPTP Typed Higher-Order Form with Rank-1 Polymorphism. In P. Fontaine, S. Schulz, andJ. Urban, editors,
Workshop on Practical Aspects of Automated Reasoning ,pages 41–55, 2016.KRSS20. M. Kohlhase, F. Rabe, C. Sacerdoti Coen, and J. Schaefer. Logic-Independent Proof Search in Logical Frameworks (short paper). InN. Peltier and V. Sofronie-Stokkermans, editors,
Automated Reasoning .Springer, 2020.KRW20. M. Kohlhase, F. Rabe, and M. Wenzel. Making Isabelle Con-tent Accessible in Knowledge in Representation Formats. see https://kwarc.info/people/frabe/Research/KRW_isabelle_19.pdf ,2020.KS19. M. Kohlhase and J. Schaefer. GF + MMT = GLF – From Languageto Semantics through LF. In D. Miller and I. Scagnetto, editors,
LogicalFrameworks and Meta-Languages: Theory and Practice , pages 24–39. OpenPublishing Association, 2019.KUV17. C. Kaliszyk, J. Urban, and J. Vyskočil. Automating formalization by sta-tistical and semantic parsing of mathematics. In M. Ayala-Rincón and C.A.Muñoz, editors,
Interactive Theorem Proving , volume 10499 of
LNCS , pages12–27. Springer, 2017. W08. F. Kamareddine and J. Wells. Computerizing mathematical text withmathlang. In M. Ayala-Rincón and E. Haeusler, editors,
Logical and Se-mantic Frameworks, with Applications , pages 5–30. ENTCS, 2008.KWZB14. F. Kamareddine, J. Wells, C. Zengler, and H. Barendregt. Computerisingmathematical text. In J. Siekmann, editor,
Computational Logic . Elsevier,2014.Ler09. X. Leroy. Formal verification of a realistic compiler.
Commun. ACM ,52(7):107–115, 2009.Lin07. S. Linton. GAP: groups, algorithms, programming.
ACM Communicationsin Computer Algebra , 41(3):108–109, 2007.Meg07. N. Megill.
Metamath: A Computer Language for Pure Mathematics . LuluPress, Morrisville, North Carolina, 2007.Mil72. R. Milner. Logic for computable functions: descriptions of a machine im-plementation.
ACM SIGPLAN Notices , 7:1–6, 1972.ML74. P. Martin-Löf. An Intuitionistic Theory of Types: Predicative Part. In
Pro-ceedings of the ’73 Logic Colloquium , pages 73–118. North-Holland, 1974.MN86. D. Miller and G. Nadathur. Higher-order logic programming. In E. Shapiro,editor,
Proceedings of the Third International Conference on Logic Program-ming , pages 448–462. Springer, 1986.MR19. D. Müller and F. Rabe. Rapid Prototyping Formal Systems in MMT: CaseStudies. In D. Miller and I. Scagnetto, editors,
Logical Frameworks andMeta-languages: Theory and Practice , pages 40–54, 2019.MRK18. D. Müller, F. Rabe, and M. Kohlhase. Theories as Types. In D. Galmiche,S. Schulz, and R. Sebastiani, editors,
Automated Reasoning , pages 575–590.Springer, 2018.MRLR17. D. Müller, C. Rothgang, Y. Liu, and F. Rabe. Alignment-based Transla-tions Across Formal Systems Using Interface Theories. In C. Dubois andB. Woltzenlogel Paleo, editors,
Proof eXchange for Theorem Proving , pages77–93. Open Publishing Association, 2017.MRS19. D. Müller, F. Rabe, and C. Sacerdoti Coen. The Coq Library as a TheoryGraph. In C. Kaliszyk, E. Brady, A. Kohlhase, and C. Sacerdoti Coen,editors,
Intelligent Computer Mathematics , pages 171–186. Springer, 2019.Nau14. Adam Naumowicz. SAT-enhanced Mizar proof checking. In Stephen M.Watt, James H. Davenport, Alan P. Sexton, Petr Sojka, and Josef Ur-ban, editors,
Intelligent Computer Mathematics - International Conference,CICM 2014, Coimbra, Portugal, July 7-11, 2014. Proceedings , volume 8543of
LNCS , pages 449–452. Springer, 2014.Nor05. U. Norell. The Agda WiKi, 2005. http://wiki.portal.chalmers.se/agda .NPW02. T. Nipkow, L. Paulson, and M. Wenzel.
Isabelle/HOL — A Proof Assistantfor Higher-Order Logic . Springer, 2002.ORS92. S. Owre, J. Rushby, and N. Shankar. PVS: A Prototype Verification Sys-tem. In D. Kapur, editor, , pages 748–752. Springer, 1992.Pau94. L. Paulson.
Isabelle: A Generic Theorem Prover , volume 828 of
LectureNotes in Computer Science . Springer, 1994.PC93. L. Paulson and M. Coen. Zermelo-Fraenkel Set Theory, 1993. Isabelledistribution, ZF/ZF.thy.PS99. F. Pfenning and C. Schürmann. System description: Twelf - a meta-logicalframework for deductive systems. In H. Ganzinger, editor,
Automated De-duction , pages 202–206, 1999. ab13. F. Rabe. A Logical Framework Combining Model and Proof Theory. Math-ematical Structures in Computer Science , 23(5):945–1001, 2013.Rab17. F. Rabe. How to Identify, Translate, and Combine Logics?
Journal of Logicand Computation , 27(6):1753–1798, 2017.Rab18. F. Rabe. A Modular Type Reconstruction Algorithm.
ACM Transactionson Computational Logic , 19(4):1–43, 2018.Ran11. A. Ranta.
Grammatical Framework: Programming with Multilingual Gram-mars . CSLI Publications, 2011.RK13. F. Rabe and M. Kohlhase. A Scalable Module System.
Information andComputation , 230(1):1–54, 2013.RS09. F. Rabe and C. Schürmann. A Practical Module System for LF. In J. Ch-eney and A. Felty, editors,
Proceedings of the Workshop on Logical Frame-works: Meta-Theory and Practice (LFMTP) , pages 40–48. ACM Press,2009.S +
13. W. Stein et al.
Sage Mathematics Software . The Sage Development Team,2013. .SSCB12. G. Sutcliffe, S. Schulz, K. Claessen, and P. Baumgartner. The TPTP TypedFirst-Order Form with Arithmetic. In N. Bjørner and A. Voronkov, editors,
Logic for Programming, Artificial Intelligence , pages 406–419. Springer,2012.Sut09. G. Sutcliffe. The TPTP Problem Library and Associated Infrastruc-ture: The FOF and CNF Parts, v3.5.0.
Journal of Automated Reasoning ,43(4):337–362, 2009.TB85. A. Trybulec and H. Blair. Computer Assisted Reasoning with MIZAR. InA. Joshi, editor,
Proceedings of the 9th International Joint Conference onArtificial Intelligence , pages 26–28. Morgan Kaufmann, 1985.Wen11. M. Wenzel. Isabelle as a document-oriented proof assistant. In J. Dav-enport, W. Farmer, J. Urban, and F. Rabe, editors,
Intelligent ComputerMathematics , pages 244–259. Springer, 2011.Wie07. F. Wiedijk. The QED Manifesto Revisited. In
From Insight to Proof,Festschrift in Honour of Andrzej Trybulec , pages 121–133, 2007.Win14. W. Windsteiger. Theorema 2.0: A System for Mathematical Theory Explo-ration. In H. Hong and C. Yap, editors,
International Congress on Mathe-matical Software , pages 49–52. Springer, 2014.WKR17. T. Wiesing, M. Kohlhase, and F. Rabe. Virtual Theories – A UniformInterface to Mathematical Knowledge Bases. In J. Blömer, I. Kotsireas,T. Kutsia, and D. Simos, editors,
Mathematical Aspects of Computer andInformation Sciences , pages 243–257. Springer, 2017.WKU18. Q. Wang, C. Kaliszyk, and J. Urban. First experiments with neural trans-lation of informal to formal mathematics. In F. Rabe, W.M. Farmer, G.O.Passmore, and A. Youssef, editors,
Intelligent Computer Mathematics , vol-ume 11006 of
LNCS , pages 255–270. Springer, 2018.Wol12. Wolfram. Mathematica, 2012., pages 255–270. Springer, 2018.Wol12. Wolfram. Mathematica, 2012.