As explained above, the major parts of query processing are implemented
'SU_messages' module in the file
library('SU_messages') through the following extendible
'SU_messages':query_class(+QueryClass, -Prompt, -InputMethod, -MapMethod, -FailureMode)
'SU_messages':query_input(+InputMethod, +Prompt, -RawInput)
'SU_messages':query_map(+MapMethod, +RawInput, -Result, -Answer)
This is to enable the user to change the language used, the processing done, etc., simply by changing or replacing the library('SU_messages') file.
To give more control to the user and to make the system more robust (for
example if the
'SU_messages' module is corrupt) the
so-called four step procedure is used in the above three
cases—obtaining the query class parameters, performing the query input
and performing the mapping. The four steps of this procedure, described
below, are tried in the given order until the first one that succeeds.
Note that if an exception is raised within the first three steps, a
warning is printed and the step is considered to have failed.
user:query_class_hook/5in case of the query class. If this hook predicate exists and succeeds, it is assumed to have done all necessary processing, and the following steps are skipped.
'SU_messages'module is called (this is the default case, these are the predicates listed above). Normally this should succeed, unless the module is corrupt, or an unknown query-class/input-method/map-method is encountered. These predicates are extendible, so new classes and methods can be added easily by the user.
'SU_messages'is called. This is necessary because the library('SU_messages') file is modifiable by the user, therefore vital parts of the Prolog system (e.g. the toplevel query) could be damaged.