Why does a type check of an unknown type not produce an error?

[schwidom]

(ins)?- type::check( integer, 0).
true. % ok

(ins)?- type::check( integer, a). 
ERROR: Unhandled exception: Unknown message: type_error(integer,a) % ok

(ins)?- type::check( r8zfkxwkiw, a).
false. % ?

When I accidentially misspelled a type, it just fails. I think it would be better to have an error.

(ins)?- must_be( nonneg, 0).
true. % ok

(ins)?- catch( must_be( nonneg, -1), E, true).
E = error(type_error(nonneg, -1), _). % ok

(ins)?- catch( must_be( r8zfkxwkiw, -1), E, true).
E = error(existence_error(type, r8zfkxwkiw), _). % ok

Thanks in Advance,
Frank Schwidom

[pmoura]

Main reason: performance. Note that the type object provides a type type that you can use to check that a type is supported:

?- type::check(type, integer).
true.

?- type::check(type, r8zfkxwkiw).
ERROR: Unhandled exception: Unknown message: domain_error(type,r8zfkxwkiw)

[schwidom]

When I write

 type::check( r8zfkxwkiw, a) -> true ;  type::check(type, r8zfkxwkiw) .

the performance should be ok.

[schwidom]

Thanks for your answers so far. I do not really see, at which point the check has a performance problem and I cannot imagine a usecase for returning false when the type is unknown. But it is as it is. Maybe it is already too late to change it.

[pmoura]

See the type object implementation of the type-checking predicates. The main type-checking predicate, check/2, is declared multifile:

https://logtalk.org/manuals/libraries/types.html#defining-new-types

To throw an error on a unknown type would require a defaulty representation and thus the use of cuts, resulting in a performance penalty when calling the type-checking predicates (each call would result in the creation of a choice-point, followed by its destruction).