Testing the Signature

Once the signature is compiled, it is possible to test the results of the compilation. To test whether or not a type exists, use the following query: [Code]

  | ?- type(Type).
  
  Type = bot ?;
  
  Type = cat ?;
  
  Type = synsem ?

  yes

Note that the prompt | ?- is provided by Prolog, while the query consists of the string type(Type)., including the period and a return after the period. Prolog then responds with instantiations of any variables in the query if the query is successful. Thus the first solution for Type that is found above is Type = bot. After providing an instantiation representing the solution to the query, Prolog then provides another prompt, this time in the form of a single question mark. After the first prompt above, the user typed a semicolon and return, indicating that another solution is desired. The second solution Prolog found was Type = cat. After this prompt, the user requested a third solution. After the third solution, Type = synsem, the user simply input a return, indicating that no more solutions were desired. These two options, semicolon followed by return, and a simple return, are the only ones relevant for ALE. If the anonymous variable _ is used in a query, no substitutions are given for it in the solution. If there are no solutions to a query, Prolog returns no as an answer. Consider the following two queries:

  | ?- type(bot).

  yes

  | ?- type(foobar).

  no

In both cases, no variables are given in the input, so a simple yes/no answer, followed by another prompt, is all that is returned.

The second useful probe on the signature indicates type subsumptions and type unifications. To test type subsumption, use the following form of query: [Code]

  | ?- sub_type(X,Y).

  X = and,
  Y = and ?;

  X = backward,
  Y = backward ?

  yes

Note that with two variables, substitutions for both are given, allowing the possibility of iterating through the cases. In general, wherever a variable may be used in a query, a constant may also be used. Thus sub_type(synsem,forward). is a valid query, as are sub_type(synsem,X) and sub_type(Y,forward). The first argument is the more general type, with the second argument being the subtype.

Type unifications are handled by the following form of query: [Code]

  | ?- unify_type(T1,T2,T).

The interpretation here is that T1 unified with T2 produces T3. As before, any subset of the three variables may be instantiated for the test and the remaining variables will be solved for.

The following query will indicate whether given features have been defined and can also be used to iterate through the features if the argument is uninstantiated: [Code]

  | ?- feature(F).

Feature introduction can be tested by: [Code]

  | ?- introduce(F,T).

which holds if feature F is introduced at type T.

Type constraints can be tested using: [Code]

  | ?- show_cons(Type).

which will display the description of the constraint assigned to the type, Type.

Finally, the inherited appropriateness function can be tested by: [Code]

  | ?- approp(Feat,Type,Restr).

A solution indicates that the value for feature Feat for a type Type structure is of type Restr. As usual, any of the variables may be instantiated, so that it is possible to iterate through the types appropriate for a given feature or the features appropriate for a given type, the restrictions on a given feature in a fixed type, and so on.

There is one higher-level debugging routine for the signature that outputs a complete specification for a type, including a list of its subtypes and supertypes, along with the most general feature structure of that type (after all type inference and constraint satisfaction has been performed). An example of the show_type/1 query is as follows: [Code]

  | ?- show_type functional.

  TYPE: functional
  SUBTYPES: [forward,backward]
  SUPERTYPES: [synsem]
  MOST GENERAL SATISFIER: 
       functional
       ARG synsem
       RES synsem

If synsem had any appropriate features, these would have been added, along with their most general appropriate values.