head 1.59; access; symbols; locks ulrich:1.59; strict; comment @# @; 1.59 date 2016.11.14.07.29.42; author ulrich; state Exp; branches; next 1.58; 1.58 date 2016.11.14.07.15.01; author ulrich; state Exp; branches; next 1.57; 1.57 date 2010.07.26.13.29.37; author ulrich; state Exp; branches; next 1.56; 1.56 date 2010.07.19.21.17.37; author ulrich; state Exp; branches; next 1.55; 1.55 date 2010.07.19.20.20.07; author ulrich; state Exp; branches; next 1.54; 1.54 date 2010.01.20.20.37.56; author ulrich; state Exp; branches; next 1.53; 1.53 date 2009.11.27.17.51.27; author ulrich; state Exp; branches; next 1.52; 1.52 date 2009.11.26.13.51.33; author ulrich; state Exp; branches; next 1.51; 1.51 date 2009.11.10.01.39.05; author ulrich; state Exp; branches; next 1.50; 1.50 date 2009.10.29.00.35.30; author ulrich; state Exp; branches; next 1.49; 1.49 date 2009.10.29.00.33.51; author ulrich; state Exp; branches; next 1.48; 1.48 date 2009.10.21.20.28.48; author ulrich; state Exp; branches; next 1.47; 1.47 date 2009.10.21.20.27.46; author ulrich; state Exp; branches; next 1.46; 1.46 date 2009.10.21.20.27.11; author ulrich; state Exp; branches; next 1.45; 1.45 date 2009.10.15.15.15.07; author ulrich; state Exp; branches; next 1.44; 1.44 date 2009.10.12.08.52.41; author ulrich; state Exp; branches; next 1.43; 1.43 date 2009.10.12.08.13.02; author ulrich; state Exp; branches; next 1.42; 1.42 date 2009.10.10.11.25.14; author ulrich; state Exp; branches; next 1.41; 1.41 date 2009.10.10.11.19.32; author ulrich; state Exp; branches; next 1.40; 1.40 date 2009.10.10.11.17.46; author ulrich; state Exp; branches; next 1.39; 1.39 date 2009.10.10.11.15.25; author ulrich; state Exp; branches; next 1.38; 1.38 date 2009.10.09.21.12.21; author ulrich; state Exp; branches; next 1.37; 1.37 date 2009.10.07.14.34.53; author ulrich; state Exp; branches; next 1.36; 1.36 date 2009.10.06.13.38.26; author ulrich; state Exp; branches; next 1.35; 1.35 date 2009.10.04.11.25.27; author ulrich; state Exp; branches; next 1.34; 1.34 date 2009.10.04.02.06.53; author ulrich; state Exp; branches; next 1.33; 1.33 date 2009.10.02.13.52.32; author ulrich; state Exp; branches; next 1.32; 1.32 date 2009.10.02.13.46.20; author ulrich; state Exp; branches; next 1.31; 1.31 date 2009.10.02.13.45.57; author ulrich; state Exp; branches; next 1.30; 1.30 date 2009.09.23.11.07.51; author ulrich; state Exp; branches; next 1.29; 1.29 date 2009.09.23.10.48.02; author ulrich; state Exp; branches; next 1.28; 1.28 date 2009.09.22.21.22.06; author ulrich; state Exp; branches; next 1.27; 1.27 date 2009.09.22.20.51.30; author ulrich; state Exp; branches; next 1.26; 1.26 date 2009.09.22.20.30.38; author ulrich; state Exp; branches; next 1.25; 1.25 date 2009.09.22.20.01.17; author ulrich; state Exp; branches; next 1.24; 1.24 date 2009.09.21.15.12.50; author ulrich; state Exp; branches; next 1.23; 1.23 date 2009.09.21.13.02.40; author ulrich; state Exp; branches; next 1.22; 1.22 date 2009.09.21.13.02.02; author ulrich; state Exp; branches; next 1.21; 1.21 date 2009.09.20.00.22.43; author ulrich; state Exp; branches; next 1.20; 1.20 date 2009.09.19.18.55.58; author ulrich; state Exp; branches; next 1.19; 1.19 date 2009.09.19.18.51.46; author ulrich; state Exp; branches; next 1.18; 1.18 date 2009.09.19.18.39.34; author ulrich; state Exp; branches; next 1.17; 1.17 date 2009.09.19.18.38.57; author ulrich; state Exp; branches; next 1.16; 1.16 date 2009.09.19.18.32.45; author ulrich; state Exp; branches; next 1.15; 1.15 date 2009.09.19.18.23.35; author ulrich; state Exp; branches; next 1.14; 1.14 date 2009.09.19.17.59.54; author ulrich; state Exp; branches; next 1.13; 1.13 date 2009.09.19.17.55.37; author ulrich; state Exp; branches; next 1.12; 1.12 date 2009.09.18.06.14.22; author ulrich; state Exp; branches; next 1.11; 1.11 date 2009.09.17.17.40.46; author ulrich; state Exp; branches; next 1.10; 1.10 date 2009.09.17.17.23.12; author ulrich; state Exp; branches; next 1.9; 1.9 date 2009.09.17.13.08.27; author ulrich; state Exp; branches; next 1.8; 1.8 date 2009.09.17.12.43.50; author ulrich; state Exp; branches; next 1.7; 1.7 date 2009.09.17.12.42.30; author ulrich; state Exp; branches; next 1.6; 1.6 date 2009.09.16.17.37.22; author ulrich; state Exp; branches; next 1.5; 1.5 date 2009.09.16.17.21.21; author ulrich; state Exp; branches; next 1.4; 1.4 date 2009.09.14.16.06.51; author ulrich; state Exp; branches; next 1.3; 1.3 date 2009.09.11.15.28.57; author uwn; state Exp; branches; next 1.2; 1.2 date 2009.09.09.10.18.40; author uwn; state Exp; branches; next 1.1; 1.1 date 2009.08.28.19.39.37; author uwn; state Exp; branches; next ; desc @@ 1.59 log @Improved situation for Permission Error @ text @
open(File, Mode, Stream)
has the following error defined:
The argument
- f)
Stream
is not a variable
—type_error(variable, Stream)
Stream
should be unified with a
stream-term (7.10.2), more specifically (7.10.2.1):
A standard-conforming program shall make no assumptionsIt is therefore possible for a standard conforming processor to reuse stream-terms for different mutually exclusive file operations. This can be observed in many processors such as SICStus 3, SWI, YAP.
about the form of the stream-term, except that:It is implementation dependent whether or not the pro-
- a) It is a ground term.
- b) It is not an atom.
- c) It uniquely identifies a particular stream during the
time that the stream is open.
cessor uses the same stream-term to represent different
source/sinks at different times.
YAP version Yap-6.0.0 ?- open(t, write, S), close(S), open(t, write, S). ERROR!! TYPE ERROR- open(t,write,$stream(3)): expected unbound variable, got $stream(3) ?- open(t, write, S), close(S), open(t, write, S2), S == S2. S = S2 = '$stream'(3) ? ; noWhereas the first query produces the required
type_error(variable,S)
, the second clearly shows
that success could have been possible.
In all other situations, type errors mean semantically failure. Type errors are signaled in situations "where the type of an argument or one of its components is incorrect but not a variable" (7.12.2 b). This particular case is the only exception. In fact, the intention of type errors was to replace silent failures previously found in most systems by more meaningful messages. So only in situations where a silent failure (or another erroneous outcome) would happen otherwise, type errors appear appropriate. Clearly, this is not the case here.
An implementation that did guarantee unique identifiers was Quintus Prolog according to Richard O'Keefe. Uniqueness was guaranteed as long as identifiers were referenced within the system. Nevertheless, even such an implementation profits from an error for an instantiated stream as it would prevent opening a file that can no longer be closed explicitly.
The error classification of 13211-1 (7.12.2) has turned out to be surprisingly robust, even for unanticipated cases. It seems that the particular situation is the only one where an existing error needs a new error class.
open/4,3
(8.11.5) in an existing standard. However, this kind of error is also
needed in the following areas:
gensym/2
frequent implementation specific built-in
predicate.
library(error): must_be/2
Error reporting library by Wielemaker and O'Keefe
[user] ?- exception_handler(arg(a,f(1),_), error(type_error(_,_),_), fail).Which is different from
catch/3
as it traps the exception in the
context where it occurs, not where the catch
goal is called and allows
local repair, replacing the result to that returned by the Handler
Goal (fail).
The following technical corrigendum reflects the resolution in Edinburgh 2010.
Clause b: Remove variable
from the enumerated set.
Add additional clause k:
uninstantiation_error(Culprit)
where Culprit
is the argument or one of its components
which caused the error.
a type errorby
an uninstantiation error
— type_error(variable, Stream).
by
— uninstantiation_error(Stream).
Below is the actual discussion that led to the name uninstantiation error. We will thus first look at the existing conventions in 13211-1.
An error for unexpected instantiations can easily be circumvented in
case no error should be produced. If a goal p(Term)
leads to this error, the error can be prevented by
using p(NewVar), NewVar = Term
.
Error_term | Error situation | Example |
---|---|---|
a)
| An instantiation is expected, but a variable is found instead. | X =.. Y. — instantiation_error.
|
b)
| A term of type ValidType is expected, but Culprit
is found instead.
| X =.. [foo|bar]. — type_error(list, [foo|bar]).
|
c)
| Similarly, a domain is expected. | X =.. []. — domain_error(non_empty_list, []).
|
d)
| The existence of Culprit as an object of
ObjectType is expected, but it does not exist.
| ex_nihilo. — existence_error(procedure, ex_nihilo/0).
|
e)
| The permission for doing
Operation onto Culprit as of type PermissionType is expected,
but the permission is not given.
| open('/etc/shadow', read,S). — permission_error(open, source_sink, '/etc/shadow')
|
f)
| A representation for some term is expected, but none
can be provided by the system.
| functor(F, f, 1000). — representation_error(max_arity).
In this case, we expected that f/1000 can be represented.
Systems whose max_arity is smaller than 1000 will produce this error. |
g)
| An (error-free) evaluation is expected,
but Error happened during evaluation.
| X is 1/0. — evaluation_error(zero_divisor).
|
h)
| A resource is expected to be available, but it is not/not enough of it is left. |
length(L,L). — resource_error(stack).
|
i)
| Text of correct syntax is expected for a Prolog text, but some
invalid syntax described by Imp_dep_atom was found
instead.
|
read(X). with "a b".— syntax_error(operator_expected).
|
j)
| A functioning system was expected, but a malfunctioning system is present instead. | Hopefully, this error never happens! |
k)
| A term with property uninstantiation was expected, but the instantiated term
Culprit was found instead.
| open('/dev/zero',read,S), open('/dev/null',read,S). — uninstantiation_error(imp_dep(2314))
|
Abstentions: 3.
uninstantiation_error
pro: 113.193 uninstantiated: A variable is uninstantiated
when it is not instantiated.
3.96 instantiated: A variable is instantiated with re-
spect to a substitution if application of the substitution
yields an atomic term or a compound term.A term is instantiated if any of its variables are instantiated.
3.146 read-option: A compound term with uninstanti-
ated * arguments which amplifies the results produced
by the built-in predicate read-term/3 (8.14.1) and the
bootstrapped * built-in predicates based on it (see 7.10.3).
Apart from above terminology entries (3), uninstantiated is used only once: note 3 of the description of bagof/3 (8.10.2.1).Remark: In 7.10.3 the read-options are
variables/1
,variable_names/1
,singletons/1
.
freeness_error
pro: 9+ The opposite of bound is free.
+ In 13211-1 free is used to refer to free variables of a term with respect to another term (7.1.1.4) - a notion needed for bagof/3 (8.10.2) and setof/3 (8.10.3). So the two uses would not collide.
- On the other hand, free variables are used in a slightly different meaning in 7.1.1.4
7.1.1.4 Free variables set of a termThat is, it is insufficient to be a variable alone to be a free variable.
The free variables set, FV, of a termT
with respect to a
termV
is a set of variables defined as the set difference
of the variable set (7.1.1.1) ofT
and BV where BV is a
set of variables defined as the union of the variable set ofV
and the existential variables set (7.1.1.3) ofT
.
+ Freeness analysis is a well established notion in the context of (logic) program analysis. It determines which terms are variables at a certain point in time. Freeness analysis is clearly seen as being separate from aliasing analysis.
- The terms "free variable" and "bound variable" have their classical meaning in logic (e.g., all the variables in a clause are bound by the implicit quantifier), so overloading them within the context of logic programming appears problematic.
subinstantiation_error
pro: 1underinstantiation_error
.
noninstantiation_error
unboundness_error
unbound_argument_error
range_error
A range error occurs when an output argument was supplied with
an illegal value. This is similar to a type error or a domain error, except
that it is a hint that a variable would be a good thing to supply instead;
type and domain errors are associated with input arguments, where a variable
would usually not be a good idea. The exception code associated with a
range error is
range_error(Goal, ArgNo, TypeName, Culprit)
This has the same arguments as a type error. Most built-in predicates
do not raise any range errors. Instead they fail quietly when an output
argument fails to unify.
Note that the situation in Quintus is slightly different to the
situation of unexpected instantiations. This can be seen best by
considering the errors for the Quintus
predicate asserta/2
. If the reference happens to be the
same, no error is produced. While this is quite improbable it is
still possible to guess a reference a priori. Or to print out a
reference and reuse it in another system. In any case, the Quintus
error depends on the success when unifying a term and not only on the
instantiation.
The name range collides with the following uses in 13211-1:1995:
- asserta(+Clause, -Ref)
- Ref
- <db_reference> a database reference which uniquely identifies the newly asserted Clause.
- Description:
- Ref should be uninstantiated; a range exception is signalled if Ref does not unify with its return value. This exception is signalled after the assert has been completed.
- Exceptions:
- range_error if Ref does not unify with the returned database reference.
3.22 byte: An integer in the range [0..255]...
6.3.4 Compound terms - operator notation
...
The priority of an operator is an integer in the range R, where
R = {r, r ∈ Z | 1 ≤ r ≤ 1200}
7.11 Flags
...
Each flag has a permitted range of values; any other
value is a Domain Error (7.12.2 c).
8.17.1.1 set_prolog_flag/2 ...The name collides with the first CD (N92 1992-03) 7.11.11 Range error, which closely corresponds to a domain error.
a) Associates Value with the flag Flag (7.11), where
Value is a value that is within the implementation
defined range of values for Flag,
The name collides with ECLiPSe-Prolog's synonymous Domain Error.
anti_instantiation_error
uniqueness_error
unboundedness_error
variableness_error
variable_error
Also, the name itself might be easily misunderstood, as this might suggest that the error is changeable. (I.e. variable ≈ changeable). Further, what we actually want is not only a free variable (in 13211-1 a variable consistently means a free variable), but a free and unaliased variable.
freevar_error
freesubvar_error
underinstantiation_error
under_instantiation
seems to be problematic, as this can
be easily confused with the frequently used locution "goal under
instantiation".
distinctness_error
cessation_error
noaliasing_error
vacuity_error
unbound_error
representation_error(variable)
type_error(variable, Culprit)
as it does not imply a
semantic failure. On the other hand representation errors shall be
issued if an implementation defined limit has been breached
(7.12.2 f). The promise behind is that in principle this
error would vanish if the implementation improves. This is the case
for integers: By going from a 32-bit system to a 64-bit system a lot
of representation errors will vanish for a processor with bounded
integers. Similarly for character codes going from ASCII to more.
However,
representation_error(variable)
will never vanish as
this is not a limit in the implementation. So the promise behind will
never be fulfilled.
misinstantiation_error
malinstantiation_error
malbinding_error
over_instantiation_error
argument_already_bound_error
overbinding_error
hyperbinding_error
hyperinstantiation_error
PermissionType
for doing
Operation
onto Culprit
is expected,
@
1.57
log
@Prior to new number
@
text
@d7 1
a7 1
nnn_error(Culprit)
nnn_error(imp_dep(2314))
@
1.56
log
@New collision for range error
@
text
@d97 6
d111 1
d239 2
a240 3
In the following technical corrigendum Nnn and
nnn_error
should be replaced by an appropriate name for
that error class.
d255 1
a255 1
nnn_error(Culprit)
d275 1
a275 1
a nnn error
d289 1
a289 1
— nnn_error(Stream).
d295 2
a296 1
The only thing that is left open is the precise name of that nnn. We
d423 4
d431 1
a431 19
freeness_error
pro: 9+ The opposite of bound is free.
+ In 13211-1 free is used to refer to free variables of a term with respect to another term (7.1.1.4) - a notion needed for bagof/3 (8.10.2) and setof/3 (8.10.3). So the two uses would not collide.
+ Freeness analysis is a well established notion in the context of (logic) program analysis. It determines which terms are variables at a certain point in time. Freeness analysis is clearly seen as being separate from aliasing analysis.
- The terms "free variable" and "bound variable" have their classical meaning in logic (e.g., all the variables in a clause are bound by the implicit quantifier), so overloading them within the context of logic programming appears problematic.
uninstantiation_error
pro: 2range_error
freeness_error
pro: 8unboundness_error
noninstantiation_error
freeness_error
pro: 7freeness_error
pro: 6misinstantiation_error
malinstantiation_error
malbinding_error
malbinding_error
misinstantiation_error
malinstantiation_error
over_instantiation_error
open(File, Mode, Stream)
@
1.37
log
@Quintus details
@
text
@d418 1
a418 1
+In 13211-1 free is used to refer to free variables of a term with d486 3 a488 2 Note that the use is not identical to our proposal. This can be seen best by considering the errors for the Quinuts d491 4 a494 1 still possible to guess a reference a priori. a499 1
subinstantiation_error
pro: 1underinstantiation_error
.
uninstantiation_error
pro: 1+ In the context of (logic) program analysis, freeness analysis determines which terms are variables at a certain point in time. Freeness analysis is clearly seen as being separate from aliasing analysis. @ 1.33 log @Move Quintus up @ text @d91 1 d416 1 a416 1
The opposite of bound is free. d418 1 a418 1
In 13211-1 free is used to refer to free variables of a term with d422 1 a422 1
In the context of (logic) program analysis, freeness analysis d427 5 d512 2 a513 2 a) Associates Value with the flag Flag (7.11), where Value is a value that is within the implementation @ 1.32 log @*** empty log message *** @ text @a464 9
unboundness_error
noninstantiation_error
anti_instantiation_error
anti_instantiation_error
freeness_error
pro: 5vacuity_error
over_instantiation_error
d114 1 a114 1d432 1 a432 1d437 1 a437 1d445 1 a445 1d450 1 d452 1 @ 1.24 log @*** empty log message *** @ text @d114 1 a114 1c) It uniquely identifies a particular stream during the d142 1 d153 1 d220 1 @ 1.23 log @New change in 8.1.3 necessary @ text @d69 1 a69 1 Neumerkel
a523 37
I believe that while the intention to produce an error in this situation certainly is appropriate, this particular error is not. 1. Type errors are signaled in situations "where the type of an argument or one of its components is incorrect but not a variable". However, a variable is found in this situation. 2. The intention of type errors was to replace silent failures previously found in most systems by more meaningful messages. So only in situations where a silent failure (or another erroneous outcome) happens otherwise, type errors appear appropriate. Alas, this is not the case here. Let me illustrate this point with SICStus 3.12: ... My motivation to discuss this relatively small issue is not so much driven by the desire to have a clean definition for open/3, but rather the detrimental effect this has on clean errors in user defined library predicates. In concreto there where three situations in SWI-Prolog where this unfortunate type_error was signaled (genysm/2, must_be/2, put_attr/3). (Fortunately they all have been replaced by representation errors in the meantime.) Further, this inconsistent error makes error diagnosis more complex. ...
gensym/2
(frequent implementation specific built-in
predicate)
d189 12
a200 2
years), the first system to permit silent failure for Type/Domain
Errors: probably IF/Prolog
a207 4
An error for unexpected instantations can easily be circumvented in
case no error should be produced. If a goal p(Term)
leads to this error, the error can be prevented by
using p(NewVar), NewVar = Term
.
d209 2
d212 1
d255 1
d259 7
d370 1
a370 1
nnn_error(id_2314)
d395 4
d419 4
a422 1
3.146
d424 5
a432 4
subinstantiation_error
pro: 1underinstantiation_error
.
a515 5
In clause 8.11.5.3 f a particular error for open is defined:
f) Stream is not a variable
- type_error(variable, Stream).
a528 15
[ulrich@@gupu ~]$ sicstus --iso
SICStus 3.12.1 (x86-linux-glibc2.2): Mon Apr 18 19:57:04 CEST 2005
Licensed to complang.tuwien.ac.at
| ?- open(t, write, Stream), close(Stream), open(t, write, Stream).
! Type error in argument 3 of open/3
! variable expected, but '$stream'(1075995992) found
! goal: open(t,write,'$stream'(1075995992))
| ?- open(t, write, Stream), close(Stream), open(t, write, Stream2), Stream = Stream2.
Stream = '$stream'(1075995992),
Stream2 = '$stream'(1075995992) ?
yes
| ?-
Whereas the first query produces that type_error(variable,V), the
second clearly shows that success could have been possible.
a529 2
In all other situations type errors mean semantically failure, except
in this particular situation.
@
1.20
log
@*** empty log message ***
@
text
@d299 1
a299 1
freeness_error pro: 5
uninstantiation_error pro: 1
subinstantiation_error pro: 1
representation_error(variable)
representation_error(variable)
will never vanish as
this is not a limit in the implementation.
@
1.18
log
@*** empty log message ***
@
text
@d310 1
a310 1
well known, so may also uninstantiation could become a notion?
d334 2
a335 1
instantiation that is less than what an instantiation usually is.
d393 1
a393 1
representation_error(variable)
over_instantiation_error
representation_error(variable)
type_error(variable, Culprit)
to the semantically
d412 1
a412 2
expected to represent the term as a variable, but the term cannot be
represented as such. On the other hand representation errors shall be
@
1.15
log
@Jan
@
text
@d298 2
a299 2
representation_error(variable)
.
d403 2
a404 2
issued if an implementation defined limit has been breached. The promise behind is that in principle @ 1.14 log @Removed the cons as essentially all entries would need them otherwise @ text @d69 1 a69 1 Neumerkel
type_error(variable, Culprit)
to a semantically
less problematic term representation_error(variable)
. It is
d402 3
a404 3
this error could be removed, if the implementation changes. This is
the case for integers, but also for character codes. However,
representation_error(variable)
will never be removed, as
@
1.10
log
@*** empty log message ***
@
text
@d260 1
a260 1
open/3,4
in
an existing standard. However, this kind of error is also needed in
the following areas:
d107 2
a108 1
gensym/2
(frequent built-in predicate)
d296 3
a298 2
gensym/2
d115 1
a115 1
representation_error(variable)
. It is
@
1.5
log
@More contributors during WLP
@
text
@d74 1
d304 2
a312 4
representation_error(variable)
.
@
1.1
log
@Initial revision
@
text
@d69 1
a69 1
Neumerkel and Markus Triska, 2009-08-27 (Version
d111 2
a112 2
In the following technical corrigendum Nnnn and
nnnn_error
should be replaced by an appropriate name for
d127 1
a127 1
nnnn_error(Culprit)
d147 1
a147 1
— nnnn_error(Stream).
d152 1
a152 1
The only thing that is left open is the precise name of that nnnn. We
d255 2
a256 2
nnnn_error(Culprit)
nnnn_error(id_2314)
a400 3
@