[m-dev.] require_tail_recursion(name/arity, [none])

[Zoltan Somogyi]

On Fri, 5 Jun 2026 15:35:52 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> On Fri, 5 Jun 2026 at 14:47, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> > Would anyone object if I replaced this syntax with a new pragma
> > named suppress_tail_recursion(name/arity)? It would make documenting it
> > significantly easier. (The internal representation already corresponds to the
> > proposed new syntax, because it is clearer.)
> 
> Is that not conflating two things? The requirement that a predicate
> uses constant
> stack space with warning suppression about a lack of tail recursion.

I guess suppress_non_tail_recursion_{diagnostic,warning} would be 
more descriptive names. Would something like that make you happy?

However, other than that possible misunderstanding, there is no conflation here:
requiring constant stack space IS requiring tail recursion, and the only effect
of a requirement not being met is a diagnostic. The pragma's name implicitly says
it is asking for a diagnostic if the requirement is not met. Using that same name
to FORBID the diagnostic seems counterintuitive.

The existing require_tail_recursion pragma controls diagnostics in one of two ways:

- in the usual case where --warn-non-tail-recursion is not set, it ENABLES diagnostics
  about non-tail recursion for a pred or func, and

- in the case where --warn-non-tail-recursion IS set, it can DISABLE those very same
  diagnostics for a pred or func.

People can now do the latter by specifying the option "none". This option is completely
different from all the other options, and is also incompatable with all of them.
Instead of trying to describe this clusterfck in the manual, I would prefer to
simply describe a simple pragma that disables these diagnostics for a pred or func
in the presence of --warn-non-tail-recursion.

I am not proposing any change in semantics, only in syntax.

> The name require_tail_recursion fits with the other assertion-like constructs
> in the language (e.g. require_det, require_feature_set).

Yes, but the whole point of the proposed new pragma is to NOT require something.
Including "require" in the name of such a construct seems ... counterproductive.

Zoltan.