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_listfor the 3rd argument, but strangely the required error term here istype_error(list,Operator). This results in (see examples)
op(30,xfy,0) =====> error(type_error(list,0))where
type_error(atom,0)ortype_error(atom_or_atom_list,0)would be more appropriate (but note thatatom_or_atom_listis not among the ValidTypes listed in 7.12.2!). For ECLiPSe we have therefore opted fortype_error(list,Op)only ifOpis an improper list, andtype_error(atom,Op)ifOpis 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_listThere 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_options_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)
Optionsis neither a partial list nor a list
—type_error(list, Options)....
e) An element
Eof theOptionslist is neither a
variable nor a valid write-option
—domain_error(write_option, E).
atom_or_atom_listThis 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)
Operatoris neither a partial list nor a list nor an
atom
—type_error(list, Operator).g) An element
Eof theOperatorlist 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_termThe 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_codeThere 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)
Codeis an integer but not an in-character code
(7.1.2.2)
—representation_error(in_character_code).
io_modeThis 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)
Modeis an atom but not an input/output mode
—domain_error(io_mode, Mode).
character_code_listSimilar 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.