# Glossary of terms used in the Mercury compiler

assertion
  A particular form of promise which claims to the compiler that the specified goal will always hold. If useful, the compiler may use this information to perform optimisations.
class context
  The typeclass constraints on a predicate or function.
codeinfo
  Originally, the data structure that holds the state of the LLDS code generator. Now, the data structure that holds the static part of the state of the LLDS code generator.
HLDS
  The "High Level Data Structure". A compiler writer would call this an AST or abstract syntax tree, because it is an internal representation of the source code. It is "abstract" because it has been stripped of irrelevant detail such as comments and redundant parentheses. It is actually an annotated AST, because the compiler attaches quite a lot of information to its nodes, specifying information such as the determinism of each goal.
inst
  Instantiatedness. An inst holds five different sorts of information.
  - It indicates whether the program point to which it applies is reachable or not.
  - It indicates whether a variable is free, partially bound, or ground.
  - It indicates whether a value is unique, or whether it may be aliased.
  - If a variable is bound, it may indicate which functor(s) the variable can be bound to.
  - For higher order values, it indicates the modes of its arguments.
liveness
  This term is used to mean two quite different things!
  - There is a notion of liveness used in mode analysis: a variable is live if either it or an alias might be used later on in the computation.
  - There is a different notion of liveness used for code generation: a variable becomes live (is "born") when the register or stack slot holding the variable first acquires a value, and dies when that value will definitely not be needed again within this procedure. This notion is low-level because it could depend on the low-level representation details (in particular, `no_tag' representations ought to affect liveness).
LLDS
  The "Low Level Data Structure". A compiler writer would call this an IR or intermediate representation. It is an internal representation of the assembly-code-like target C code that the LLDS backend generates. It stores data in registers and stack slots, and uses (conditional or unconditional) gotos for control transfer.
MLDS
  The "Medium Level Data Structure". A compiler writer would call this an IR or intermediate representation. It is an internal representation of the high level language code that the MLDS backend generates, which we can output as C, Java or C# code. It stores data in variables, and uses if-then-elses, while loops and calls for control transfer.
mode
  This has two meanings:
  - The mode of a single variable: a mapping from one instantiatedness to another.
  - The mode of a predicate: a mapping from an initial instantiatedness of a predicate's arguments to their final instantiatedness.
module_info
  Another name for the HLDS.
NYI
  Not Yet Implemented.
pred_info
  The structure in the HLDS which contains information about a predicate or a function. (The compiler views arity-N functions as arity-(N+1) predicates, with last argument being the function result.)
proc (procedure)
  A particular mode of a predicate or a function.
proc_info
  The structure in the HLDS which contains information about a procedure.
promise
  A declaration that specifies a law that holds for the predicates/functions in the declaration. Thus, examples of promises are assertions and promise ex declarations. More generally, the term promise is often used for a declaration where extra information is given to the compiler which it cannot check itself, for example in purity pragmas.
promise ex
  A shorthand for promise_exclusive, promise_exhaustive, and promise_exclusive_exhaustive declarations. These declarations are used to tell the compiler the determinism properties of a disjunction.
RTTI
  The "RunTime Type Information". See rtti.m. A copy of a paper on this topic is available here in zipped Postscript format.
super-homogenous form (SHF)
  A simplified, flattened form of goals, where each unification is split into its component pieces. In particular, the arguments of each predicate call and functor must be distinct variables, and each unification may include at most one functor.
switch
  A disjunction which does a case analysis on the toplevel functor of the term bound to some variable.