Thank you for your quick reply, Ulrich. Some comments inline.
On Tue, Jun 2, 2026 at 3:59 PM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
b and c are probably the options possible. b is done in Ichiban and Tau.
As for an unbounded max_arity, yet an error for too large arities of procedures, there are three systems: SWI, YAP, ECLiPSe. ECLiPSe produces an uncatchable, non-conforming error, YAP has its own non-conforming error class embedded in a conforming error/2. Only SWI produces representation_error(max_procedure_arity).
The question is only who needs to know about max_procedure_arity. In particular in systems that do not have this problem since they have a rather low max_arity. 255 seems to be most popular.
Making such a change for one system seems a little bit exaggerated. In particular given than in 14 other systems there is currently no advantage.
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/max_arity
It isn't quite one system, though. Of the five that report max_arity = unbounded (Ichiban, Tau, ECLiPSe, SWI, YAP), three impose a procedure-arity limit (ECLiPSe at 255, SWI at 1024, YAP at 16383). The other two simply have no limit. And of those three, only SWI signals it conformingly. ECLiPSe's error is uncatchable and YAP's is a system error wrapped in error/2. An optional, implementation-defined max_procedure_arity wouldn't really be a change for one system; it gives the two currently non-conforming ones a target to converge on.
But now, assuming this gets added. One possibility could be to add an implementation defined Prolog flag max_procedure_arity, to make this discoverable. And to demand nothing from a system where max_arity is good enough. Nothing except accompanying documentation. Maybe.
A discoverable flag sounds right, but I think it leaves my actual question open: is the error term representation_error(max_procedure_arity) itself acceptable? The flag lets you check the limit in advance, while the error is what you catch when you hit.
Portable code needs to know whether What = max_procedure_arity is sanctioned or just a vendor extension to a special case.
In any case, quite related is
?- current_predicate(p/1000000). false. % 8.8.2.3 representation_error(max_arity), unexpected. % SICStus, GNU, Minerva, Cx type_error(predicate_indicator,p/1000000), unexpected. % X, ECLiPSe, Ciao
It works as expected in the latest Ciao playground ( https://ciao-lang.org/playground/), which is a bit ahead of the latest distributed source version. We will let you know when the next release is available, as it makes some significant ISO compliance progress.