[m-dev.] for review: default modes for higher-order func insts

[Fergus Henderson]

On 03-Aug-2001, David Overton <dmo at cs.mu.OZ.AU> wrote:
> Implement a change to the mode system suggested by Ralph Becket to make use of
> higher order functions a bit easier.

There should really be some documentation of this in the Mercury language
reference manual.

The most difficult part of this diff to review is all of the places that
you *didn't* change.  There's a high likelihood of some existing code
not doing the right thing for the new semantics of `ground'.

However, I have done my best.  One thing I noticed is that the code
for propagating higher-order types into insts in mode_util.m isn't
needed anymore, and should be deleted.  But because of the difficulty
in reviewing, the change will need careful testing.

> compiler/inst_match.m:
> 	In 'inst_matches_initial' and 'inst_matches_final', ensure that higher
> 	order inst information is not lost from non-standard function insts.
> 	Also allow 'inst_matches_{initial,final,binding}' to succeed
> 	where the first inst is a standard function inst and the
> 	second is ground.

I think you should also add some comments to inst_is_ground explaining
what it does for non-standard function insts, and why.  Currently it
succeeds, which I think is the right thing for most callers, but not for
all.  There is at least one place where this issue with inst_is_ground
leads to a bug with your current diff because of somewhere that
you didn't change.

You need go through every call to inst_is_ground and see whether it
is OK for each call to succeed for non-standard function insts.  This will
require searching up the call graph in some cases (e.g. you'll need to
look at all callers of mode_is_fully_input and mode_is_fully_output).

> +++ compiler/inst_util.m	2 Aug 2001 15:05:03 -0000
> @@ -98,6 +98,25 @@
>  	%       the same in both.
>  
>  %-----------------------------------------------------------------------------%
> +
> +	% Succeed iff the first argument is a function pred_inst_info
> +	% with non-standard mode.
> +
> +:- pred pred_inst_info_is_nonstandard_func_mode(pred_inst_info, module_info).
> +:- mode pred_inst_info_is_nonstandard_func_mode(in, in) is semidet.

s/with non-standard mode/whose mode does not match the standard func mode/

e.g. this predicate fails for "func(in) = uo", because that matches
the standard func mode "func(in) = out", even though it isn't the same
as the standard func mode.

(Might be worth adding the preceding sentence as a comment.)

> +	% Succeed iff the first argument is a function ground_inst_info
> +	% with non-standard mode.
> +
> +:- pred ground_inst_info_is_nonstandard_func_mode(ground_inst_info,
> +			module_info).
> +:- mode ground_inst_info_is_nonstandard_func_mode(in, in) is semidet.

Likewise.

> +++ tests/hard_coded/ho_func_default_inst.m	3 Aug 2001 00:17:04 -0000
> @@ -0,0 +1,43 @@
> +% This test checks that a higher order func type with inst ground is 
> +% able to be treated as a though it has the default function mode.

I think this change needs more test cases.
The reasoning involved in handling some of the tricky cases is
quite easy to get wrong, and so even if your change gets it
right, it's important to have test cases in the test suite
to make sure that future maintainers don't mess it up.

In particular, I think it's important to test matching
of the following modes against `in':

	- modes like `func(in) = uo)'
	- modes like `func(di) = uo)'
	- modes like `func(in) = out(non_empty_list)'
	- modes like `func(in(non_empty_list)) = out'


Apart from that, this diff looks fine.  Please post another diff
(preferably relative) when you've addressed these comments.

I'm still not *entirely* sure that this approach is the right one to take,
but I do think it is worth a try.

-- 
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-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------