The last step in description compilation is to generate Prolog code based on the instructions prepared during the previous steps. In the following, we present the kind of code that is generated based on each class of instructions.
add_to_typestatements depending on the length of the path. For example,
type [dtrs], hc_structwill generate
add_to_type(phrase,dtrs,hc_struct). Remember that ALE finds the most general satisfier of a description by first finding the most general satisfier of its terminal path, in this case phrase. The above
add_to_typeinstruction says that we need to add the feature dtrs with the value restriction
hc_structto the type phrase.
Two issues need to be pointed out at this point. As mentioned before,
this specific example will not find its way to the Prolog code because
phrase types already come with the feature dtrs with the
hc_struct. The use of the example here is
only for expository purposes. Second, in practice, ALE appends the
type name with
add_to_type_ for efficiency. Therefore, the
above example would have actually appeared as
add_to_type_phrase(dtrs,hc_struct) in the generated Prolog
var(Var) -> Var=FS; ud(Var,FS)
in B to determine whether or not Var is seen at run time; if it is unseen it will then equate it with the feature structure that it refers to; otherwise, it will have to make a call to ud/2, which is unification with dereferencing.
If a variable is unseen, then it is either CBSafe or not. Recall that a CBSafe variable is safe to be bound at compile time. In this case, ALE simply performs a unification at compile time using ud/2. If the variable is not CBSafe, however, it will use Prolog equality.