lean2/doc/export_format.md

Low level format

Lean can export .lean and .hlean files in a low-level format that is easy to parse and process. The exported file contains only fully elaborated terms. The file describes hierarchical names, universe levels and expressions. These objects are used to declare inductive datatypes, definitions and axioms.

Hierarchical names

A hierarchical name is essentially a list of strings and integers. Each hierarchical name has a unique identifier: a unsigned integer. The unsigned integer 0 denotes the anonymous hierarchical name. We can also view it as the empty name. The following commands are used to define hierarchical names in the export file.

<nidx'> #s <nidx> <string>
<nidx'> #i <nidx> <integer>

In both commands, nidx is the unique identifier of an existing hierarchical name, and nidx' is the identifier for the hierarchical name being defined. The first command defines a hierarchical name by appending the given string, and the second by appending the given integer. The hierarchical name foo.bla.1.boo may be defined using the following sequence of commands

1 #s 0 foo
2 #s 1 bla
3 #i 2 1
4 #s 3 boo

Universe terms

Lean supports universe polymorphism. That is, declaration in Lean can be parametrized by one or more universe level parameters. The declarations can then be instantiated with universe level expressions. In the standard Lean front-end, universe levels can be omitted, and the Lean elaborator (tries) to infer them automatically for users. In this section, we describe the commands for create universe terms. Each universe term has a unique identifier: a unsigned integer. Note that the identifiers assigned to universe terms and hierarchical names are not disjoint. The unsigned integer 0 is used to denote the universe 0.

The following commands are used to create universe terms in the export file.

<uidx'> #US  <uidx>
<uidx'> #UM  <uidx_1> <uidx_2>
<uidx'> #UIM <uidx_1> <uidx_2>
<uidx'> #UP  <nidx>
<uidx'> #UG  <nidx>

In the commands above, uidx, uidx_1 and uidx_2 denote the unique identifier of existing universe terms, nidx the unique identifier of existing hierarchical names, and nidx' is the identifier for the universe term being defined. The command #US defines the successor universe for uidx, the #UM the maximum universe for uidx_1 and uidx_2, and #UIM is the "impredicative" maximum. It is defined as zero if uidx_2 evaluates to zero, and #UM otherwise. The command #UP defines the universe parameter with name nidx, and #UG the global universe with name nidx. Here is the sequence of commands for creating the universe term imax (max 2 l1) l2.

1 #s 0 l1
2 #s 0 l2
1 #US 0
2 #US 1
3 #UP 1
4 #UP 2
5 #UM 2 3
6 #UIM 5 4

Thus, the unique identifier for term imax (max 2 l1) l2 is 6. The unique identifier for term l1 is 3.

Expressions

In Lean, we have the following kind of expressions: variables, sorts (aka Type), constants, constants, function applications, lambdas, and dependent function spaces (aka Pis). Each expression has a unique identifier: a unsigned integer. Again, the expression unique identifiers are not disjoint from the universe term and hierarchical name ones. The following command are used to create expressions in the export file.

<eidx'> #V <integer>
<eidx'> #S <uidx>
<eidx'> #C <nidx> <uidx>*
<eidx'> #A <eidx_1> <eidx_2>
<eidx'> #L <info> <nidx> <eidx_1> <eidx_2>
<eidx'> #P <info> <nidx> <eidx_1> <eidx_2>

In the commands above, uidx denotes the unique identifier of existing universe terms, nidx the unique identifier of existing hierarchical names, eidx_1 and eidx_2 the unique identifier of existing expressions, info is an annotation (explained later), and eidx' is the identifier for the expression being defined. The command #V defines a bound variable with de Bruijn index <integer>. The command #S defines a sort using the given universe term. The command #C defines a constant with hierarchical name nidx and instantiated with 0 or more universe terms <uidx>*. The command #A defines function application where eidx_1 is the function, and eidx_2 is the argument. The binders of lambda and Pi abstractions are decorated with info. This information has no semantic value for fully elaborated terms, but it is useful for pretty printing. info can be one of the following annotations: #D, #I, #S and #C. The annotation #D corresponds to the default binder annotation (...) used in .lean files, and #I to {...}, #S to {{...}}, and #C to [...]. The command #L defines a lambda abstraction where nidx is the binder name, eidx_1 the type, and eidx_2 the body. The command #P is similar to #L, but defines a Pi abstraction. Here is the sequence of commands for creating the term fun {A : Type.{1}} (a : A), a

1 #s 0 A
2 #s 1 a
1 #US 0
1 #S 1
2 #V 0
3 #L #D 2 2
4 #L #I 1 3

Now, assume the environment contains the following constant declarations: nat : Type.{1}, nat.zero : nat, nat.succ : nat -> nat, and vector.{l} : Type.{l} -> nat -> Type.{max 1 l}. Then, the following sequence of commands can be used to create the term vector.{1} nat 3. We annotate some commands with comments of the form -- ... to make the example easier to understand.

1 #s 0 nat
2 #s 1 zero
3 #s 1 succ
4 #s 0 vector
1 #US 0
1 #C 2          -- nat.zero
2 #C 3          -- nat.succ
3 #A 2 1        -- nat.succ nat.zero
4 #A 2 3        -- nat.succ (nat.succ nat.zero)
5 #A 2 4        -- nat.succ (nat.succ (nat.succ nat.zero))
6 #C 4 1        -- vector.{1}
7 #C 1          -- nat
8 #A 6 7        -- vector.{1} nat
9 #A 8 5        -- vector.{1} nat (nat.succ (nat.succ (nat.succ nat.zero)))

Imported files

As .lean and .hlean files, the exported files may import other exported files. The import commands can be relative or absolute paths (with respect to the LEAN_PATH environment variable).

#DI <nidx>
#RI <integer> <nidx>

Paths are described using hierarchical names. The hierarchical name foo.bla.boo corresponds to the path foo/bla/boo. The command #DI is the direct import, it instructs the reader to import the file at the location corresponding to the hierarchical name nidx. The command #RI is the relative import, the integer represents how many ../ should be added the path represented by the hierarchical name nidx.

Global universe level declaration

The command

#UNI <nidx>

declares a global universe with name nidx.

Definitions and Axioms

The command

#DEF <nidx> <nidx>* | <eidx_1> <edix_2>

declares a definition with name nidx with zero or more universe parameters named <nidx>*. The type is given by the expression eidx_1 and the value by eidx_2. Axioms are declared in a similar way

#AX <nidx> <nidx>* | <eidx>

We are postulating the existence of an element with the given type. The following command declare the definition id.{l} {A : Type.{l}} (a : A) : A := a.

2 #s 0 id
3 #s 0 l
4 #s 0 A
1 #UP 3
0 #S 1
5 #s 0 a
1 #V 0
2 #V 1
3 #P #D 5 1 2
4 #P #I 4 0 3
5 #L #D 5 1 1
6 #L #D 4 0 5
#DEF 2 3 | 4 6

Inductive definitions

Mutually inductive datatype declarations are slightly more complicated. They are declared by a block of commands delimited by the command #BIND and #EIND. The command #BIND has the following form:

#BIND <integer> <integer> <nidx>*

where the first integer are the number of parameters, the second is the number of mutually recursive types being declared by the block, and nidx* is the sequence of universe parameter names. The command #EIND is just a delimiter and does not have arguments. The block is composed by commands #IND and #INTRO.

#IND <nidx> <eidx>
#INTRO <nidx> <eidx>

The command #IND declares an inductive type with name nidx and type eidx. The command #INTRO declares an introduction rule (aka constructor) with name nidx and type eidx. The first command in a block is always an #IND, the subsequent #INTRO commands are declaring the introduction rules for this inductive type.

For example, the following mutually recursive declaration

inductive tree.{l} (A : Type.{l}) : Type.{max 1 l} :=
| node  : tree_list.{l} A → tree.{l} A
| empty : tree.{l} A
with tree_list : Type.{max 1 l} :=
| nil  : tree_list.{l} A
| cons : tree.{l} A → tree_list.{l} A → tree_list.{l} A

is encoded by the following sequence of commands

2 #s 0 l
3 #s 0 tree
4 #s 0 A
1 #UP 2
0 #S 1
2 #US 0
3 #UM 2 1
1 #S 3
2 #P #D 4 0 1
5 #s 3 node
6 #s 0 a
7 #s 0 tree_list
3 #C 7 1
4 #V 0
5 #A 3 4
6 #C 3 1
7 #V 1
8 #A 6 7
9 #P #D 6 5 8
10 #P #I 4 0 9
8 #s 3 empty
11 #A 6 4
12 #P #D 4 0 11
9 #s 7 nil
13 #P #D 4 0 5
10 #s 7 cons
14 #A 3 7
15 #V 2
16 #A 3 15
17 #P #D 6 14 16
18 #P #D 6 11 17
19 #P #I 4 0 18
#BIND 1 2 2
#IND 3 2
#INTRO 5 10
#INTRO 8 12
#IND 7 2
#INTRO 9 13
#INTRO 10 19
#EIND

Exporting declarations

The command line option -E filename is used to export declarations in the format described above.