succ/2 question

[UWN]

Since Ichiban is currently one of actively developed ISO adhering system with bounded integers that are also checked, I can only ask the following question about `succ/2 to you:

?- current_prolog_flag(max_integer, Max), succ(Max, S).
2022/05/10 08:36:37 error(evaluation_error(int_overflow), 'Integer overflow.') % Perfect!
?- current_prolog_flag(max_integer, Max), succ(Max, Max).
2022/05/10 08:36:44 error(evaluation_error(int_overflow), 'Integer overflow.')
?- current_prolog_flag(max_integer, Max), succ(Max, 0).  
2022/05/10 08:36:49 error(evaluation_error(int_overflow), 'Integer overflow.')

These last two queries. Does it really make sense to produce an overflow? After all, it is evident that there cannot be a solution to the query.

Bounded integers have a lot such border cases that take a lot of time to ponder and codify. It is (partly) for this reason that many developers switched to unbounded integers. There, the moment of overflow (with gigantic numbers) is not that precisely defined, after all 7.12.2 h is possible at any stage of execution.

[ichiban]

@UWN I don't think it makes a lot of sense, but p.p.6.3.f forces it to do so.

Implementing a predicate is much like guessing the hidden procedural definition of the predicate. The error case p.p.6.3.f is strongly hinting S is X + 1 is involved since no other predicates, other than (is)/2, throw evaluation_error(int_overflow).

Interestingly, call_nth/2 throws representation_error(max_integer) instead. It might make more sense for succ/2 to do the same. "I have discovered a truly marvelous successor of the integer, which this processor's integer is too small to contain."

If p.p.6.3.f were like Flag bounded is true, x is maxint, and s is a variable - representation_error(max_integer), then I would have implemented it in a way that those two queries simply fail, but more explanation and/or examples are helpful since we'll lose the clue of evaluation_error(int_overflow).

Maybe it could be these three cases:

• succ(+integer, +integer) X =:= S - 1
• succ(+integer, -integer) S is X + 1, throws representation_error(max_integer) when x is maxint
• succ(-integer, +integer) X is S - 1

[pmoura]

The following tests are based on the common de facto standard for the succ/2 predicate: https://github.com/LogtalkDotOrg/logtalk3/blob/master/tests/prolog/predicates/succ_2/tests.lgt

[UWN]

The closest representation_error/1 with integers I often encounter is:

| ?- catch(X #> X*X,error(E,_),true).
E = representation_error(max_clpfd_integer) ? ;
no

(of SICStus). In this situation the notion of evaluation does not make any sense. And yes, that could be the case for succ/2 in a much more limited way. After all,

?- succ(X,X).
   instantiation_error. % and not false

Note that most systems just have unbounded integers and thus have much less problems in this area.

[UWN]

For one, I have added to the errors of call_nth also evaluation_error(int_overflow). How often will this error happen? Since 32-bit systems already fade away, chances are very low for the next years. But still it needs to be defined for bounded integer arithmetic.

[UWN]

Why is there now this unexpected instantiation error:

?- current_prolog_flag(max_integer, Max).
Max = 9223372036854775807;
?- succ(9223372036854775807, S).
2023/08/11 08:13:54 error(evaluation_error(int_overflow),succ/2)
?- current_prolog_flag(max_integer, Max), succ(Max, S).
2023/08/11 08:14:20 error(instantiation_error,succ/2), unexpected.