fix table

This commit is contained in:
Mark Mansi 2018-02-28 14:45:51 -06:00
parent 4835c223f5
commit 533b96b6d0
1 changed files with 2 additions and 2 deletions

View File

@ -6,8 +6,8 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo
Term | Meaning Term | Meaning
------------------------|-------- ------------------------|--------
AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely.
binder | a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and `\|a\| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) binder | a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and `&#124;a&#124; ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound)
bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `&#124;a&#124; a * 2`. See [the background chapter for more](./background.html#free-vs-bound)
codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use.
completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness").
control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg)