Which meanings of "type" are used in the standard?

Question

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?

Answer 1

There are essentially three different uses for "type" in ISO/IEC 13211-1:

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).

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 }

3. 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_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) 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.