[m-dev.] trace goals and reordering

[Julien Fischer]

On Thu, 1 May 2025 at 14:38, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> > (I don't think it would have helped much in this case, since the
> > original author of the code in question
> > assumed it was an issue with the MLDS->Java code generator,
>
> That, I would not have guessed :-)

Poor log messages and the trace goal moving made it appear as
though a value was changing between two different points in the program.

...

> > > > (If so, I think the reference
> > > > manual should mention the possibility that they can be reordered for
> > > > mode correctness.)
> > >
> > > That approach would require listing all the ways in which trace goals
> > > are like all other pure goals, which would be a long list. It seems simpler
> > > to list the small number of ways in which they are different.
> >
> > As I said above, I don't think it will hurt to mention the possibility
> > of reordering.
>
> And I am not objecting to such a mention. But you know better than me
> what the misunderstanding was, so you are in a better position to write the text
> to help people avoid that misunderstanding.

Shall do.

> > > To address the violation of the law of least astonishment that lead
> > > to this email, we could add code to after-front-end invocation of
> > > the simplification pass that, when it finds a procedure body contains
> > > a trace goal (a goal feature should signal this), does an extra traversal
> > > of the procedure body. This traversal would update the largest context
> > > seen so far, which, in the absence of source file and line number pragmas,
> > > would be the largest line number in the procedure's one-and-only file name.
> > > It would then generate a warning if, when it arrived at a trace goal, the
> > > context of the trace goal was *not* bigger than the largest context so far.
> > > This would light up trace goals that mode analysis has moved to the right.
> >
> > I debugged the problem by looking at the HLDS dumps -- I don't think that's
> > something we should be expecting most users to do.
>
> Agreed. Hence the proposal above. That one I *can* implement, if you like.

I think such a warning would be worthwhile

Julien.