
7.4.3  Instantiation: When faced with two
constants, the equal = operator invokes an equality comparison
as documented in 7.4.2 above. Where one term remains
a variable, however, the equal = operator causes Hermes
to instantiate the variable with the other term's value (typically a constant
or domain function return value).
The ingres:select domain function, cited in Fig. 715, causes
the Hermes search engine to iterate through a list of supplier records
selected for a specific part. Should the user query cite a specific supplier,
as in Fig. 716, then the equality operator highlighted in Fig. 715 gets
evaluated as a comparison between the current records Supplier
field value and the specified Supplier constant. Where the user
requests a general list of part suppliers (i.e. variable Supplier
as in Fig. 717), then
the highlighted equality operation becomes an instantiation  Hermes
instantiates the predicate Supplier variable with the current
record's Supplier field value and moves on to the next rule.

7.4.4
 The constant and variable literals each take one variable as their
term and are used to determine whether the target term is of the type indicated;
The constant literal evaluates to true if its term is instantiated to a
constant, otherwise it returns false. Likewise, the variable literal
returns true if its term is uninstantiated (and thus still a variable).
Hermes constant and variable literals serve two basic
purposes. First, domain function inputs must all be constants when the
domain function evaluates; the constant literal acts as a safety
to ensure this. Second, the constant and variable literals
provide a simple means to select among available predicate rules (where
more than one exists) based on input (which input terms are constants).
In this respect, the mediator author can tailor predicate rules to vary
according to input and ideally provide the most efficient function calls
to answer the query. In theory, there can be 2^{n} versions
of a rule where n is the predicate arity which corresponds to term instantiation
combinations. In practice, many cases can be simplified or combined; A
binary table (see Fig. 720) often proves useful for visualizing potential
rule case combinations and partitions (Note: Consider only predicate terms
which apply to domain function inputs).
The rule table in Fig. 720 shows the eight (three variables: 2^{3}
= 8) potential constant / variable term combinations
for the supplier_part relation (see Fig. 719). For this mediator,
the author chose to ignore selections by quantity; The mediator thus ignores
the Quantity term and focuses only on the Part and Supplier
terms with constant / variable tests. This effectively
drops the constant / variable term combinations to four
(highlighted in Fig. 720) as the remaining combinations render duplicates
for the Supplier and Part term combinations. Additionally,
the current ingres:select domain function can select on only one
condition at time. With this in mind, the mediator author combines two
cases, rule one and three from the Fig. 720 table, into the first mediator
predicate rule in Fig. 719. Thus the mediator provides only three rules
to address the four (highlighted) term combinations.
The first predicate rule applies where just the Part
term is, or where both Part and Supplier terms are, instantiated (constant)
and draws on the authors foreknowledge regarding the supplier_part
relation status; Since the data file commonly holds more distinct part
entries than suppliers, it's more efficient (more selective) to select
by Part than by Supplier. Where both terms are constant,
Hermes processes the equality = operator as a comparison,
vice instantiation operation. Thus the search engine will iterate thru
the selected records until it either matches the given Supplier constant,
returning true, or it runs out of records and returns false. Otherwise,
the first rule returns a list of suppliers, and available quantities, for
the specified part.
The second predicate rule applies for cases where
the user provides the Supplier but not the Part term,
Hermes executes the ingres:select domain function on Supplier,
rendering a list of parts and quantities available from the given supplier.
The final predicate rule, applicable where both Part
and Supplier terms remain variable, causes Hermes to retrieve
all relation records via the ingres:all domain function.

7.4.5
 The default literal enables Hermes to instantiate the targetvariable
term with a constant if the term remains uninstantiated at execution time;
If targetvariable term is already instantiated at execution,
then the literal simply returns true and Hermes skips to the next
rule entry. If the valueterm calls a domain function,
then it gets evaluated to a constant prior to targetvariable
instantiation. Note: Both arguments, targetvariable and
valueterm, must evaluate to the same Hermes type.
Additionally, if the valueterm remains variable at execution
time, Hermes will issue a runtime error.
A typical default literal use is to ensure that a variable has
a value as a domain function input. The factory predicate called in Fig.
722 instantiates the FactoryLongitude and FactoryLatitude
values based on the predicate Factory name input. Next, the default
literal ensures that the Radius term is instantiated prior to
allowing the quadtree:range domain function execution.
Another default literal use might be to ensure that
a variable has a an input comparison value (see reference comparison section
example i.e. default (NeedQuantity, 1)

7.4.6  The in and out literals
determine array, or set, membership of a given element. Moreover, the in
literal provides a mechanism for iterative processing of target data record
(such as domain data) source.