[m-dev.] mutual tail recursion warnings

Zoltan Somogyi zoltan.somogyi at runbox.com
Wed Sep 13 15:21:20 AEST 2017

On Wed, 13 Sep 2017 15:06:30 +1000, Peter Wang <novalazy at gmail.com> wrote:

> Hi Zoltan,
> On Wed, 13 Sep 2017 00:17:45 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > Do people think that adding an explanation along the lines of
> > "the fault for the non-tail nature of this recursive call may lie
> > in another predicate" would be sufficient to reassure programmers
> > when they can't find the fault in the predicate (in this case, odd)
> > mentioned in the error message, or should we try to avoid generating
> > the misleading error message at all?
> Can we name the predicate(s) in the SCC which is the source of the problem?

We can name the procedures in the SCC for which we have already generated
such warnings. Since we process the TSCCs within the SCC bottom up,
this will be the procedures from which the procedure in question is not
reachable via *tail* calls. If there is only one such procedure, this will be
the source of the problem; if there is more than one, then the source
of the problem may be just one of them, and we can't tell which one.

> > The latter would require
> > changing the error message about the actual source of the problem
> > (the non-tail call in even) to explain that it may affect its whole SCC,
> > not just the predicate in which it appears.
> I wouldn't necessarily think to look at the error message for another
> predicate, at least, not initially.

That is the problem I am trying to fix, yes. But did you intend that comment
to argue for or against either course of action listed above?


More information about the developers mailing list