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

[Julien Fischer]

On Wed, 10 Jun 2026 at 17:48, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> On Wed, 10 Jun 2026 17:37:52 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> > > 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.

Trailing inhibits tail recursion in certain (fortunately rare) circumstances.
Specifically, when we add trail ops. to a model_det or model_semi
disjunction, we add some trail ops. after each disjunct goal in order to
handle the commit.

The attached test case is a contrived example of this.  In non-trailing
 MLDS grades it is tail-recursive, but in trailing MLDS grades it is not
tail recursive (and we get a warning because of the pragma).

I'm not sure what the situation with the LLDS backend is. (It adds
trail ops. directly in the code generator, as opposed to using
add_trail_ops.).

Julien.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trail_non_tailcall.m
Type: application/octet-stream
Size: 555 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260610/80b178d8/attachment.obj>