As explained above, the major parts of query processing are implemented
in the 'SU_messages'
module in the file
library('SU_messages') through the following extendible
predicates:
'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/5
in 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.