[m-rev.] for post-commit review: fix goal_form.m XXX

[Peter Moulder]

Minor point: the can_loop/can_throw functions do not do a complete
analysis; sometimes they return `yes' when a deeper analysis would show
that in fact the goal cannot loop/throw.  Thus, they ought to be called
may_loop/may_throw, consistent with usage in Mercury documentation (and
the naming of the other external preds/funcs of that module, I believe).

At the least, it would be good for the documentation comments in the
interface section to clarify this (e.g. say `may' rather than `can').

Although not very important, addressing it may help someone in the
future debugging a problem because they wrongly assume that can_foo will
return `no' (because the person knows that the goal cannot foo).  It may
also act as a hint that improving this analysis may be one option if
callers perform badly (i.e. get "don't know" answers more often than the
programmer would expect/want).

(The corresponding cannot_foo names arise just because there's no
obvious better name for the negation of may_foo; known_cannot_foo is
the best alternative that springs to mind.)


I didn't notice any other problems; though I've only looked at the
posted line-by-line diffs, rather than applying and using a graphical
word-by-word diff program; the line-by-line diffs make it difficult to
see how the behaviour of external procs has changed.

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