There is a gap somehow. max_arity only covers the compound size. But there is no flag for predicate size. The two things might vary as SWI-Prolog shows. But SWI-Prolog names the limit wrongly max_arity, although its not its max_arity flag
That looks interesting, since max arity for data may be much larger (e.g, dictionaries) than arity for predicate heads in human-written code.
Would it be worth adding some flags to distinguish both limits? E.g., compound_max_arity for data vs. head_max_arity for code.
This is also relevant for dictionaries. Depending on the encoding, max number of keys may be half the size of max_arity for compounds.
I’m curious about reasonable arity limits nowadays. Unbounded arity sounds good, but a limit of 1<<27 that means that a single term (in 64 bits) with atomic arguments can have a size of 1GB. It does not look reasonable to encode data so large as plain terms.
This issue shows up in several of the logtalk3/tests/prolog/unbound tests. Having two new flags with a fallback to the max_arity flag when not available would be useful.
Given the ISO standard describes the max_arity flag as “for any compound term”, ECLIPSe solution would only require agreement in a single additional flag, max_predicate_arity. I prefer this solution. SWI-Prolog provides max_procedure_arity, however.
I like both max_procedure_arity or max_predicate_arity.
The change may be too small for a PIP but perhaps we can collect a few more de-facto non-ISO flags? (like version_data, dialect, integer/float min/max, gc, etc.)