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.