In part one of the ISO standard for Prolog, ISO/IEC 13211-1:1995, the notion of "type" is used to refer to different things. This often leads to confusion.
For example, a page called IsoErrata (archived version, source) states (note that this page is not related to ISO):
7.12.2 and 8.1.2.1
There is a confusion about what a "type" is. There seem to be 3
different groups:
- Those that are listed in 8.1.2.1 and also occur as ValidTypes in type_error terms in 7.12.2.b
- Those that are listed in 8.1.2.1 and occur as ValidDomain in domain_error terms in 7.12.2.c
- Those that are listed in 8.1.2.1 only
In addition, there are ValidDomains in 7.12.2.c that are not listed in
8.1.2.1, presumably by mistake (eg. io_mode).
8.14.3.3.f
The template requires the type atom_or_atom_list for the 3rd argument, but strangely the required error term here is
type_error(list,Operator). This results in (see examples)
op(30,xfy,0) =====> error(type_error(list,0))
where type_error(atom,0) or type_error(atom_or_atom_list,0) would be more appropriate (but note that atom_or_atom_list is not among the
ValidTypes listed in 7.12.2!). For ECLiPSe we have therefore opted for
type_error(list,Op) only if Op is an improper list, and
type_error(atom,Op) if Op is any other non-atom.
So in which meanings is "type" used, and what to do about above confusion?
There are essentially three different uses for "type" in ISO/IEC 13211-1:
Types as defined in 7.1 Types. These are: variable (7.1.1), integer (7.1.2), floating point (7.1.3), atom (7.1.4), compound term (7.1.5) and some types based on them. The next two uses will often refer to 7.1 or to terminology (3 Definitions) for its definition. What is important is that here, variables are included. This classification is motivated by Prolog's syntax:
7.1 Types
The type of any term is determined by its abstract syntax (6.1.2).
Types as defined in 7.12.2 b. These are the types that are used in type errors which are of the form type_error(ValidType, Culprit). Note that variables are now no longer included since these are either signaled as instantiation errors (7.12.2 a) or uninstantiation errors (7.12.2 k, Cor.2).
ValidType ∈ { atom, atomic, byte, callable, character, compound, evaluable, float, in_byte, in_character, integer, list, number, pair, predicate_indicator }
Types as used in the Template and modes subclause:
8.1.2.1 Type of an argument
The type of each argument is defined by one of the following atoms:
atom, atom_or_atom_list, atomic, byte, callable_term, character, character_code, character_code_list, character_list, clause, close_options_list, compound_term, evaluable, flag, head, in_byte, in_character, in_character_code, integer, io_mode, list, nonvar, number, operator_specifier, predicate_indicator, read_options_list, source_sink, stream, stream_options_list, stream_or_alias, stream_position, stream_property, term, write_options_list
Above quote mentioned only 7.12.2 and 8.1.2.1 and how they relate to each other. So this needs some more elaboration:
Types of 7.12.2 are reported with type errors. But types in 8.1.2.1 only serve in the Template and modes subclause of the definition of a built-in. They are not per se suited to be used for errors. In a concrete definition of a built-in predicate, there is a subclause x.y.z.2 Template and modes and x.y.z.3 Errors. Here are some examples of types of 8.1.2.1 (bold in the list above).
write_options_list
There is no direct one-to-one correspondence between write_options_list and the concrete types used in the errors. Instead, a type list and a domain write_option is used. So the complex type write_option_list is never signaled:
8.14.2.2 Template and modes
write_term(@stream_or_alias, @term, @write_options_list)
8.14.2.3 Errors
...
c) Options is neither a partial list nor a list
— type_error(list, Options).
...
e) An element E of the Options list is neither a
variable nor a valid write-option
— domain_error(write_option, E).
atom_or_atom_list
This is even more complex. On the one hand an atom list is expected, but also an atom is fine. So we have list and atom as relevant types:
8.14.3.2 Template and modes
op(+integer, +operator_specifier, @atom_or_atom_list)
8.14.3.3 Errors
...
f) Operator is neither a partial list nor a list nor
an
atom
— type_error(list, Operator).
g) An element E of the Operator list is neither a
variable nor
an atom
— type_error(atom, E).
It is equally plausible to produce atom for error f. On the other hand, both errors are equally applicable, and list is definitely the best for malformed lists like [a|nonlist], whereas atom is not necessarily better for 111 which might be an OCR error of [l].
callable_term
The corresponding type error contains callable. Like in
8.10.1.2 Template and modes
findall(?term, +callable_term, ?list)
8.10.1.3 Errors
...
b) Goal is neither a variable nor a callable term
— type_error(callable, Goal).
in_character_code
There is neither a corresponding type in 7.12.2 b, nor a domain in 7.12.2 c. But in 7.12.2 f it is defined for representation errors:
8.12.1.2 Template and modes
...
get_code(?in_character_code)
get_code(@stream_or_alias, ?in_character_code)
8.12.1.3 Errors
...
j) Code is an integer but not an in-character code
(7.1.2.2)
— representation_error(in_character_code).
io_mode
This is listed in 8.1.2.1, contrary to the quoted text. It also appears in 7.12.2 c and is used:
8.11.5.3 Errors
...
h) Mode is an atom but not an input/output mode
—
domain_error(io_mode, Mode).
character_code_list
Similar to write_options_list. However, it is erroneously mentioned in 7.12.2 c. That's an error in the standard which has been removed in Cor.3:2017.
