[m-dev.] mutual tail recursion warnings

[Peter Wang]

On Wed, 13 Sep 2017 15:21:20 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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.

That sounds good.

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

For the first suggestion, with the addition above if possible.

Peter