Code Generation

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.

• type:
  These instructions are translated into a series of add_to_type statements depending on the length of the path. For example, type [dtrs], hc_struct will 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_type instruction says that we need to add the feature dtrs with the value restriction hc_struct to 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 value restriction 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 code.

• var:
  Variables in an instruction are either seen or unseen. If a variable is seen, then a Prolog equality is generated. Some variables are tricky, however. This means that in a disjunction (A;B), the variable Var has been used in A, and at compile time, it is not possible for ALE to determine whether Var is seen in B or not. In such cases, ALE generates a shallow cut as in

  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.

• fs:
  Feature structures are treated like seen variables, and therefore, they are handled with ud/2 as well.

• ineq:
  Inequations are handled with Prolog's dif/2 predicate, which constrains its arguments to represent non-unifiable values.

• fun:
  Function calls are directly transferred to Prolog as function calls.

• or:
  Disjunctions are handled as Prolog disjunctions.