Dear all,
representation_error(max_arity) is defined relative to the max_arity flag. That's fine for predicates like functor/3 and (=..)/2, but it's also specified for predicate-indicator predicates like abolish/1 and current_predicate/1.
The trouble is that some systems make compound-term arity unbounded (or quite large) while still limiting predicate arity. On SWI:
?- functor(H, foo, 2000). % ok ?- functor(H, foo, 2000), assertz(H). % representation_error(max_procedure_arity)
SWI Prolog solves the issues by splitting max_arity from max_procedure_arity (the latter isn't ISO). Eclipse Prolog also has two different limits but error is underreported (ambiguous). Picat, although not a Prolog system, also has two different limits (probably rooted in B-Prolog).
That is definitely a problem and most of the ISO tests suites I have available either fail here or ignore those cases. Some possible directions:
a) force one limit for terms and predicates (simplest but not a solution) b) raise limit for predicate arity (but that can be a *significant* implementation effort with low ROI) c) use max_procedure_arity (and push for future standardization) d) keep reporting max_arity for both limits, use error context (not standard) to disambiguate which arity limit has been reached
I lean towards (c) looking for a possible change in the standard, or (d) as a temporary solution.
(b) is difficult because some limits are intrinsically hard to raise in some engines (every reasonable computer language has some kind of procedure argument limits). A fallback calling convention may help but the implementation cost is not trivial.
What are your opinions?
Thanks,
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
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.
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
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.
?- 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.
I very much doubt that other currently conforming implementations are willing to add that flag, which to them is useless.
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.
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).
#7 up to #11 added, in particular w.r.t. discoverability
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/max_arity#9
That is definitely a problem and most of the ISO tests suites I have available either fail here or ignore those cases.
The only way how all systems can discover this flag is via #11.
Which particular test suites are you referring to?
The comparison table suggests that there are many other unrelated issues to resolve. The flag as such is currently an implementation specific extension (5.5.8).
On Wed, Jun 3, 2026 at 10:11 AM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
#7 up to #11 added, in particular w.r.t. discoverability
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/max_arity#9
That is definitely a problem and most of the ISO tests suites I have available either fail here or ignore those cases.
The only way how all systems can discover this flag is via #11.
Which particular test suites are you referring to?
Our ISO compliance tests are collected from several sources and put together at: - https://github.com/ciao-lang/iso_tests (see https://github.com/ciao-lang/iso_tests/blob/master/src/iso_tests.pl for a description and sources)
It is not complete and imperfect (sits on top of a module/3 declaration, which is non-standard), but we are giving it a push. The 84.91% pass is currently at 89.22%.
The comparison table suggests that there are many other unrelated issues to resolve. The flag as such is currently an implementation specific extension (5.5.8).
Thanks
Prolog-standard mailing list -- prolog-standard@software.imdea.org To unsubscribe send an email to prolog-standard-leave@software.imdea.org
prolog-standard@software.imdea.org
-
Jose F. Morales -
Ulrich Neumerkel