[m-dev.] trace goals and reordering

[Zoltan Somogyi]

On Thu, 1 May 2025 12:18:22 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> I was recently debugging an issue in one of our applications where some log
> messages were emitted in an unexpected order. The log messages are generated by
> calls inside trace goals and it turned out that one of the trace goals was
> being reordered in order to be mode correct. The attached program is a very
> simplified example of this.

As far as I remember, I did not modify mode analysis when I added trace goals,
which means that they can be reordered like any other scope.

> The reference manual says the following about trace goals:
> 
>     The compiler will not delete trace goals from the bodies of the procedures
>     containing them, even though they are 'det' and have no outputs. In their
>     effect on program optimizations, trace goals function as a kind of
> impure code,
>     but one with an implicit promise_pure around the clause in which they occur
> 
> This seems a bit vague. What is meant by "kind of impure code"?

The vagueness is hard to avoid, since listing precisely how a long list of optimizations
handle trace goals would be far less readable than what is there now :-(

The intention behind that sentence, which I think I wrote, is simply to say that
the compiler will not delete a det trace goal with no outputs. The compiler normally
does eliminate such goals *unless* they are impure; this sentence modifies that
to "unless they are either impure or are trace goals". That's it. Feel free to make
that clearer.

> At least as
> far as reordering due to modes is concerned, the implementation does not seem
> to treat them as impure. Is that intentional?

Yes, though the intention was mostly to simplify the implementation, not to benefit
users. But allowing a trace goal to work even if it is textually before the code
that generates a value that the trace goal prints out *can* be considered
a benefit; it's in the eye of the beholder.

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

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.

Whether this approach would yield more nuisance warnings than useful
warnings is something that I don't think we can decide without trying it out.

Zoltan.