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.

--
Jose