On Wed, Jun 3, 2026 at 11:46 AM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
?- current_prolog_flag(F,Version),sub_atom(F,_,_,_,version),current_prolog_flag(max_procedure_arity,A).
A = 255, F = version_data, Version = ciao(1,25,0,commit_info(master,b868c430bd7e2997db8672f2f85c432c3dfc7ab5,'2026-03-05 18:53:14 +0100','1.25-v1.21-1934-gb868c430bd')) ?
So now you have added this flag, even if in your implementation max_arity would be good enough.
We added it months ago, when we raised the compound-term arity limit; there was some discussion at https://discourse.prolog-lang.org/ before we decided. Since then max_arity and the procedure limit no longer coincide (we genuinely have two limits now) so max_arity alone cannot report both.
I very much doubt that other currently conforming implementations
are willing to add that flag, which to them is useless.
On the head-count, I'd gently note that "unbounded terms, bounded procedures" is a direct consequence of the execution model that traditionally makes systems fast. SWI, YAP and ECLiPSe (and now Ciao, arguably Picat/B-Prolog too) arrived at it independently, from the same constraint. So it is not unreasonable that a system with a single 255 limit would find the flag useful the moment it raises its compound-arity limit, which is exactly what happened to us.
Codifying that max_procedure_arity specifies that restriction *in case it is present* seems to be good enough. That means, that other implementations are now restricted in the sense that if they add that flag, it must have the current meaning, so they cannot use that flag name to mean something else.
Agreed!
Reserving the name to that meaning is good. Systems with two limits can report it under a name portable code can rely on. Same role bounded, max_integer and min_integer play (still useful despite systems moving towards bignum arithmetic).