[m-rev.] for review: document require_tail_recursion pragmas

[Zoltan Somogyi]

On Wed, 10 Jun 2026 17:37:52 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > > > +The exception applies to conjunctions that contain two or more recursive calls,
> > > > +as in the recursive clause of quicksort.
> > > > +Since obviously only the last of these calls can be a tail call,
> > >
> > > Delete "obviously".
> >
> > Why?
> 
> It seems redundant.

I am keeping it. It does not add any info, but it was meant to add emphasis,
not information.

> > > > + at item in_all_grades
> > > > +Tell the compiler to generate a diagnostic for non-tail recursion
> > > > +even in grades that do not allow the possibility of tail recursion.
> > > > +In such grades, which include debugging and deep profiling grades,
> > >
> > > s/include/includes/
> > >
> > > I suggest emphasising that as well.
> >
> > If there are any other such grades, I would prefer to list them explicitly.
> > Do you know any?
> 
> As mentioned elsewhere, the agc grades do, but they're not publicly documented.
> Do the various forms of minimal model tabling prevent it?

Yes, and I will mention them.

> > Does trailing disable tail recursion?
> 
> No, it doesn't. It might alter what is considered tail recursive, due to calls
> to trail management operations being inserted

All grades that prevent tail recursion do so by adding invisible-to-the-user
operations after what, at the user level, seems to be a tail call. If trailing
can do this as well, then it should be listed.

And I will need to modify mark_tail_calls.m to actually generate the warnings
for seemingly-but-not-really tail recursive calls that the manual says it should
generate. At the moment, for invisible code added by a code generator, it does not.

> although I'd need to think
> about the interaction between the two in more detail.

When you have a conclusion, yea or nay, please tell me.

Zoltan.