[m-rev.] diff: reset contains_trace_goal if necessary

Mark Brown mark at csse.unimelb.edu.au
Thu Nov 9 17:53:28 AEDT 2006


On 09-Nov-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> On Thu, Nov 09, 2006 at 04:10:41PM +1100, Mark Brown wrote:
> > > What's dubious about optimising a promised pure goal away?
> > Because the promise might be incorrect, and if it is the result of
> > optimising it away can be quite confusing.  Note that if the programmer
> > has gone to all the trouble of calling an impure predicate with its
> > intended side-effects, and then promises that there are no side-effects,
> > I think this is likely to be a bug.
> 
> *Any* promise might be wrong, and the consequences could be pretty
> confusing.  I don't think by itself that's a good enough reason for a
> warning.

The key word is "likely".

> 
> You could warn about redundant goals in general, but you'd have to
> restrict the conditions pretty severely to avoid unwelcome warnings.
> It would have to be something like what Ralph said:  a det goal with
> no outputs.  It would also have to be redundant in every mode (you
> don't want to get a warning for one mode of a clause complaining about
> the redundancy of a goal that's necessary in another mode).  And the
> goal would have to appear in the clause as written by the programmer,
> not be the result of inlining or other optimizations.  And you
> shouldn't get the warning if you're using mode inference.

These are all good points, but pretty much SMOP.  We already deal with
these things when warning about simple code, for example (e.g., "the
condition of this if-then-else cannot succeed").

> 
> But I still don't think such a warning should be on by default.  I
> can't see it catching many errors,

People obviously don't come to your door when their printf-style debugging
code produces no output.  ;-)

> and I can imagine wanting to write
> redundant goals for clarity or because I'm planning to change the code
> later so that it wouldn't be redundant (though I can't think of a
> specific example).

Yes, I agree that warnings can often come up in this situation.  The most
common one I get is that a procedure is inferred erroneous but declared
det, which often happens when throwing a "not yet implemented" exception.
I don't recall anyone ever asking for this warning to be turned off by
default, though.

> And I don't like the idea that removing an unused
> mode declaration for a working predicate would cause the compiler to
> start warning about another mode.

That can already happen with `--warn-simple-code'.  I've never seen it
come up in practice.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list