El apoyo mutuo como respuesta al darwinismo

The project MathLang aims to give alternative and complete paths which trans- form mathematical texts into new computerised and/or formalised versions. These paths are intended to accommodate different degrees of formalisation, different mathematical editing/checking tools and different proof checkers. Dividing the formalisation of mathematical texts into a number of stages was first proposed by N.G. de Bruijn to relate CML to his Mathematical Vernacular [dB87] (MV) and his proof checking system Automath. We call this principle de Bruijn’s path.

The work may be subdivided. One can think of a first stage where a person with some mathematical training inserts a number of interme- diate steps whenever he feels that further workers along the belt might have trouble, and a second stage where the logical inference rules are supplied and the actual coding is carried out. For the latter piece of work one might think of a person with just some elemenary mathemat- ics training, or of a computer provided with some artificial intelligence. But we should not be too optimistic about that: programming such

jobs is by no means trivial. [dB91]

MV was proposed as a formal substitute for parts of CML. R. Nederpelt refined MV into another formal substitute for parts of CML, Weak Type Theory (WTT) whose underlying proof theory was developed by Kamareddine [NK01, KN04]. MathLang started from de Bruijn’s path idea and took R. Nederpelt’s WTT as the initial language at the lowest level in the path. Soon, MathLang was faced with the huge challenge of how to really create a path from original mathematical texts into fully formalised ones and how would this path differ for different choices of texts, text editors, logical frameworks, and proof checkers. After a number of prototypes were built, it became obvious that the stages of the path and the formal substitute of CML need to be seriously revised.

The process of designing MathLang is handled during a number of gradual phases. This iterative process is shown in Figure 2.4. The main development is based on encoding an existing mathematical text within the MathLang framework. On each iteration the MathLang framework evaluates a translation of a mathe- matical document, during which difficulties may be experienced. This leads to

Redesign formal rules for new MathLang version Redesign methodology and software for entering mathematical texts in new MathLang version Verify formal properties of new MathLang version Attempt entering mathematical texts in new MathLang version Evaluate results, assess problems, and propose solutions

Figure 2.4: The MathLang development process, presented in [KW02, KW08, KWZ08].

determine new solutions for the encountered difficulties and further design adjust- ments in MathLang. As a result this may affect the need to redesign formal rules for representing mathematics in MathLang, as well as, to redesign the methodology for capturing texts in this representation, and supporting software.

The mathematical texts chosen for the design purposes cover a wide spectrum of mathematics. Our choice is oriented toward the variety of writings by ordinary mathematicians.

We take into account a number of factors before we chose a mathematical text for encoding purposes. Among those factors are the following:

• represent the variety of mathematical writings by ordinary mathematicians rather than mathematical logicians or set-theorists,

• capture different styles of writing mathematics, as well as different mathe- matical theories, (e.g., number theory, topology, algebraic geometry etc.), • encode modern and historical mathematics,

• choose texts that have been previously formalised by others.

Extensive computerisations of different mathematical texts (some taken fully from natural language to different levels of computerisation and finally to full Mizar), continue to shape the MathLang language. Its expressiveness has been increased in comparison to MV and WTT.

The elements of the formal syntax of WTT, heavily based on MV, are classified to four linguistic/grammatical categories/levels:

1. Atomic level: variables, constants and binders, 2. Phrase level: terms, sets, nouns and adjectives, 3. Sentence level: statements and definitions, 4. Discourse level: context, lines and books.

In the terminology of WTT, a document is a book which is a sequence of lines. Each line can be decomposed as a pair of: a context and a sentence, whereas a context contains facts assumed or declared in a sentence. WTT has three different ways of introducing names: definition, declaration and context. There is a subtle difference among all three ways of introducing names. It is related to the scope (life time) of the introduced name within the document. Definition introduces a name whose scope is the part of the document following the definition and is limited to the closure tag of that part of the document where it was introduced. Furthermore, definition can have parameters whose scope is the body of the definition.

A declaration in a context introduces a name (without parameters) whose scope is only the current line. Another difference between a definition and a declaration is that definition defines a new symbol in mathematical texts, whereas a declaration introduces a new symbol primarily without representing a meaning of that symbol. Finally, a preface for a book introduces a number of names whose scope is limited to the document. Compared to the definitions, names introduced in the preface are constants (having parameters and ranges as weak types) whose meanings are not provided.

Declarations, definitions and statements can consists of phrases which are built from terms, sets, nouns and adjectives.

WTT uses a weak type system to verify and check the well-formedness of a document written/formalised in WTT. By extension a word weak, associated to the phrase type system, indicates that the typing system is light and provides a generic judgement based on those types. WTT defines eight types - book, context, statement, definition, term, set, noun and adjective - which are directly related to the grammatical categories of the abstract syntax of WTT.

WTT was considered as a mathematical vernacular for mathematicians and provides a lot of useful ideas. Although, its definition has a number of limitations. For instance, WTT does not provide nor support a way to reuse a theory or a con- cept introduced in one document within another document. This builds difficulties during the process of creating a digital library of mathematical documents written

in WTT.

WTT does not provide a clear indication/annotation of which statements are used as a reasoning to other statements. In general WTT does not deal with proofs and logical correctness.

Moreover, WTT has a lack of annotation of a mathematical roles (e.g., proof, the- orem, lemma, etc.,) for a group o statements. Furthermore, it does not allow to associate human readable labels for specific groups of statements (e.g., “Pythago- ras Theorem”).

There is no support for embedding “natural” language within the WTT formalised document. This causes the WTT formalised document to be “user unfriendly” and awkward to read.

Despite all those limitations WTT introduces the best approaches and solutions taken from MV. This was revised and provided with more clear and precise con- cepts, that evolves into a machine readable language with a weak type system. We used WTT development in the initial stages to shape the path from the common mathematical document to its fully formal representation verifiable by a computer software.