[m-rev.] new disabled test case tests/valid/field_detism.m

[Fergus Henderson]

On 23-Dec-2003, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> tests/valid/field_detism.m:
> 	New test case to test a limitation of the determinism system,
> 	caused by insufficient propagation of mode information.

I'm not yet convinced that this code is or even should be valid.

There's two issues here:
	- is this code currently valid?
	- should this code be valid?

Before putting a test case in tests/valid and thus documenting that the
code is valid, we should first make sure that it is indeed valid code
according to the language reference manual.  If it is not currently valid
code according to the language reference manual, I suppose we could still
add a test case in tests/valid, but only if we carefully document that
the test is not valid according to the current language reference manual.
Likewise if the language reference manual is ambiguous about a test's
validity.  In either case, adding the test to tests/valid should be
done only if we're convinced that the code ought to be valid, and in
that case there should be a corresponding XXX comment in the language
reference manual sources indicating which part(s) we think ought to change.

(Another alternative would be to create a new directory for test cases
which are not currently valid, but which we think ought to be.  That might
be clearer than putting them in tests/valid.  However, it would be easier
to keep track of the CVS revision history if such tests stay in the same
directory when they change status from "should be valid" to "is valid".
I could live with either approach.)

In this particular case, the validity of the code depends on the details
of how mode inference (for the automatically generated field update
function) works, and currently mode inference is not really documented
in the language reference manual.  So this falls into the category of
things whose validity is ambiguous.  But the semantics for mode inference
that I originally intended, which are the ones that I implemented,
would imply that this code is not valid.  The documentation in the HISTORY
file mentioning the addition of mode inference says "there are some modes
which the current mode inference algorithm is not capable of inferring".
This remains true today, and is not likely to change.  In particular,
the modes which the mode inference algorithm is not capable of inferring
include the deterministic mode of the field update function in this
test case,

	:- mode 'x :='(in(bound(b(ground))), in) = out.

That is because mode inference never tries to infer subtype modes.
(By "subtype mode", I mean a mode that makes use of an inst "bound(...)"
where the list of constructors in the "..." is a strict subset of
the constructors for the type.)
Instead, mode inference will infer the simpler mode

	:- mode 'x :='(in, in) = out.

which happens to be semidet.

The problem with inferring subtype modes is that it becomes difficult
to ensure termination and feasibility of the mode inference processs.

If you are suggesting that this code _should_ be valid,
then I can see two possible ways to make it so:

	1.  Change the rules for mode inference of field update functions
	    so that we somehow infer better modes for them than we would
	    for user-defined functions.

	2.  Change the rules for mode inference so that we infer better
	    modes for all functions, not just field update functions.
	    In particular mode inference should infer subtype modes
	    in at least some cases (the ones where it improves the
	    procedure's determinism?).

Either way, some analysis is needed to determine exactly what
changes to the rules are required, and to confirm that these changes do
not have any serious adverse impacts on the termination or feasibility
of the mode inference process.  Unless/until such an analysis has been
done, I do not think we can reasonably say that this test should be
valid.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------