1

SICStus Prolog offers an abstract datatype ("mutable term") for efficient backtrackable destructive assignment.

The user's manual subsection on mutable terms states:

Please note: the effect of unifying two mutables is undefined.

Let's say another Prolog system wants to implement mutable terms.

Unlike SICStus Prolog that other system wants to define the above effect using the catch / throw error mechanism.

What could be suitable error terms? According to ISO/IEC 13211-1:1995:

7.12.2 Error classification [...]

e) There shall be a Permission Error when it is not permitted to perform a specific operation. It has the form permission_error(Operation, PermissionType, Culprit) where

Operation ∈ { access, create, input, modify, open, output, reposition }

and

PermissionType ∈ { binary_stream, flag, operator, past_end_of_stream, private_procedure, static_procedure, source_sink, stream, text_stream }

and Culprit is the argument or one of its components which caused the error.

[...]

j) There may be a System Error at any stage of execution. The conditions in which there shall be a system error, and the action taken by the processor after a system error are implementation dependent. It has the form system_error.

So system_error might be an option, but I think that a permission_error would be better. How about permission_error(modify,mutable_term,(=)/2)?

repeat
  • 18,496
  • 4
  • 54
  • 166
  • 1
    In any case it always helps to go through all [error classes](http://www.complang.tuwien.ac.at/ulrich/iso-prolog/error_k#error_classes). A representation_error might be an option too. At least for `current_prolog_flag(occurs_check,error)` `representation_error(term)` seems to be the most sensible. Alternatively, a permission error might make sense too. – false Jun 28 '23 at 12:41
  • @false. Thanks for your comment! I'm not quite sure about how this is like unification with `current_prolog_flag(occurs_check,error)` which actually attempts to unify and aborts before a cyclic term is produced (this may or may not happen). What I want for the unification of two mutable terms is to throw an error upfront (without further inspection of the involved terms). – repeat Jun 28 '23 at 16:36
  • @false. Here's another reason I'd rather favor `permission_error(modify,...,(=)/2)`. Suppose the system does not support `copy_term` of mutable terms... then `permission_error(access,...,copy_term/2)` would parallel above error nicely... – repeat Jun 28 '23 at 16:47
  • 1
    Or existence error? – false Jun 28 '23 at 16:57
  • @false. Something like `existence_error(non_mutable_term,(=)/2)` and `existence_error(non_mutable_term,copy_term/2)` ? – repeat Jun 28 '23 at 16:59
  • 1
    Currently, `ObjectType` ∈ { `procedure`, `source_sink`, `stream` } So a value that fits into this somehow – false Jun 29 '23 at 05:43
  • @false. A somewhat strange, but quite literal translation of "the effect of unifying two mutables is undefined" could also be `evaluation_error(undefined)`. – repeat Jun 29 '23 at 09:08
  • @false. Alas, non-mutable terms don't fit any of the existing `ObjectType` values. – repeat Jun 29 '23 at 09:10
  • 1
    evaluation error is specific to evaluable functors. – false Jun 29 '23 at 09:19

0 Answers0