[m-dev.] [m-users.] Tail recursion optimisation
Julien Fischer
jfischer at opturion.com
Mon May 18 19:19:13 AEST 2026
On Mon, 18 May 2026 at 17:52, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Mon, 18 May 2026 16:41:12 +1000, Julien Fischer <jfischer at opturion.com> wrote:
>
> > On Mon, 18 May 2026 at 16:35, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> > >
> > > On Mon, 18 May 2026 16:33:32 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > > > It is. Those pragmas are currently undocumented however (at least
> > > > their documentation
> > > > is currently commented out.)
> > >
> > > I have already started enabling that documentation, after fixing it up.
> >
> > IIRC, the reason it wasn't enabled is that you can specify that lack
> > of tail recursion
> > should cause a compilation error. That fine in production grades,
> > like asm_fast.gc
> > or hlc.gc, but it also affects grades that do not support tail
> > recursion, like the deep
> > profiling grades (i.e. it needs to be possible to compile programs for
> > profiling without
> > having to manually edit all the require_tail_recursion pragmas.)
>
> I am in the process of fixing that, by adding a new dimension to the pragma.
> The two values of this dimension I am proposing to be named "in_all_grades"
> and "in_tailrec_grades_only", which the first calling for violations of the required
> kind of tail recursion to be reported in all grades, with the second calling for the same
> only in grades that support tail recursion in general (mostly asm_fast and hlc).
When this feature was first introduced, my suggestion was that in
grades that *cannot*
support tail recursion, we change the meaning of "error" in the pragma to emit a
warning or information message to that effect. That is less complicated than
adding the extra dimension above.
We could include some words about how to ameliorate the non-constant stack
usage in grades that don't support tail recursion (e.g. increase the stack size,
using a .stseg grade etc) and also mention that the program may need
to be profiled /
debugged with smaller inputs.
Julien.
More information about the developers
mailing list