[m-rev.] for review: test cases for clause mode annotations

[Fergus Henderson]

On 17-May-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On Thu, May 17, 2001 at 01:17:42AM +1000, Fergus Henderson wrote:
> > Index: tests/hard_coded/multimode.m
> > ===================================================================
> > +main -->
> > +	{ In = 42 },
> > +
> > +	% test pure functions
> > +	print(func0), nl,
> > +	print(func1(In)), nl,
> > +	print(func1(_Out0)), nl,
> > +	%print(func2(In, In)), nl,
> > +	print(func2(In, _Out1)), nl,
> > +	print(func2(_Out2, In)), nl,
> > +	print(func2(_Out3, _Out4)), nl,
> 
> > +:- pragma promise_pure(func2/2). % XXX technically this is a lie
> > +:- func func2(int, int) = string.
> > +%:- mode func2(in, in) = out is det.
> > +:- mode func2(in, out) = out is det.
> > +:- mode func2(out, in) = out is det.
> > +:- mode func2(out, out) = out is det.
> > +%func2(_::in, _::in) = (R::out) :-
> > +%	R = "func2(in, in) = out".
> 
> Why is that mode commented out?

Ah, a good question.  I forgot about that.

We don't pass the test case if it is left in.
The compiler selects the wrong mode -- the `(in, out) = out'
mode rather than the `(in, in) = out' mode, and then reports
a determinism error.

I'm not sure if selecting the wrong mode here is a bug or not.
But in any case, it is not related to the use of different
clauses for different modes; the same thing occurs even if
the only clause for func/2 is a single clause with a call to error/1.
That's why I commented it out.  I intended to put a more detailed
comment here, and to add the problem as a separate test case,
but I forgot about it; thanks for the reminder.
You're doing a great job of keeping me honest ;-)

On further investigation, I see that the problem goes way if the call
is written slightly differently: if instead of

	print(func2(In, In)), nl,

it is

	{ In2 = In },
	print(func2(In, In2)), nl,

then it works fine.

I think the problem here is that we flatten things in the wrong order
(top-down rather than bottom-up), so the original code flattens to

	F = func2(In, V_42),
	V_42 = In

rather than to

	V_42 = In,
	F = func2(In, V_42)

and hence mode inference sees a call in mode (in, out) = out
rather than in mode (in, in) = out.  Note that mode reordering
is only done to satisfy the modes, not the determinism,
so mode analysis won't reorder it back to the bottom-up ordering.

I'll uncomment the commented-out lines, 
changing the problematic one to

	{ In2 = In },
	print(func2(In, In2)), nl,

to avoid the problem.

I'll also add a new test case tests/valid/mode_selection.m
which exhibits the problem.  This case will not be enabled,
since we don't yet pass it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  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
--------------------------------------------------------------------------