[m-dev.] for review: polymorphic ground insts

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Feb 26 16:36:29 AEDT 2000


On 21-Feb-2000, David Overton <dmo at ender.cs.mu.oz.au> wrote:
> |inst_matches_final_3(ground(UniqA, _), bound(UniqB, ListB), MaybeType,
> |		ModuleInfo, _Exps) :-
>  	unique_matches_final(UniqA, UniqB),
>  	bound_inst_list_is_ground(ListB, ModuleInfo),
> |	uniq_matches_bound_inst_list(UniqA, ListB, ModuleInfo),
> |	(
> |		MaybeType = yes(Type),
> |		% We can only do this check if the type is known.
> |		bound_inst_list_is_complete_for_type(set__init, ModuleInfo,
> |			ListB, Type)
> |	;
> |		true
> |		% XXX enabling this check makes the mode checker too
> |		% conservative in the absence of alias tracking.
> |	).

It's not clear from the XXX comment what code ought to be put
there when alias tracking is enabled.

Also, won't the lack of alias tracking cause problems even
in the case where the type is known?

> +inst_matches_binding_3(ground(_UniqA, _), bound(_UniqB, ListB), MaybeType,
> +		ModuleInfo, _Exps) :-
> +	bound_inst_list_is_ground(ListB, ModuleInfo),
> +	(
> +		MaybeType = yes(Type),
> +		% We can only do this check if the type is known.
> +		bound_inst_list_is_complete_for_type(set__init, ModuleInfo,
> +			ListB, Type)
> +	;
> +		true
> +		% XXX enabling this check makes the mode checker too
> +		% conservative in the absence of alias tracking.
> +	).

Likewise here.

> --- ./mercury/compiler/inst_util.m	Fri Feb 11 10:45:01 2000
> +++ .././mercury/compiler/inst_util.m	Wed Feb 16 14:36:39 2000
> @@ -297,7 +297,9 @@
>  abstractly_unify_inst_3(live, ground(UniqX, constrained_inst_var(Var)),
>  		any(UniqY), Real, M, ground(Uniq, constrained_inst_var(Var)),
>  		semidet, M) :-
> -	Real = fake_unify, % AAA
> +	Real = fake_unify, 
> +		% If Real \= fake_unify then we must fail because the inst vars
> +		% may represent higher order insts.
>  	unify_uniq(live, Real, det, UniqX, UniqY, Uniq).

Hmm, I don't think failing is the right thing to do there.

If I write

	:- pred p(T, T).
	:- mode p(in(I), in(I)) is semidet.
	p(X, Y) :- X = Y.

then that should be allowed, even though `I' might be a higher-order inst.
The situation is very similar to

	:- pred p(T, T).
	:- mode p(in, in) is semidet.
	p(X, Y) :- X = Y.

which is allowed, but which will throw an exception at runtime if T is a
higher-order type.  I think the treatment of these two situations should
be the same.

> +++ .././mercury/compiler/mercury_to_mercury.m	Fri Feb 11 11:20:12 2000
> @@ -688,7 +688,6 @@
>  		mercury_output_tabs(Indent),
>  		mercury_output_var(Var, VarSet, no),
>  		io__write_string("\n")
> -		% AAA
>  	;
>  		{ GroundInstInfo = none},
>  		mercury_output_uniqueness(Uniq, "ground"),
> @@ -761,7 +760,6 @@
>  	;
>  		{ GroundInstInfo = constrained_inst_var(Var) },
>  		mercury_output_var(Var, VarSet, no)
> -		% AAA

Are you using the right VarSet there?

> @@ -1445,28 +1445,37 @@
>  			ArgModes0, ArgModes1) },
>  		{ mode_list_get_initial_insts(ArgModes1, ModuleInfo,
>  			InitialInsts) },
> +
> +		% Compute the inst_var substitution from the initial insts
> +		% of the called procedure and the insts of the argument
> +		% variables.
>  		{ map__init(InstVarSub0) },
> -		lift(recompute_instmap_delta_call_1(Args, VarTypes, InstMap,
> +		lift(compute_inst_var_sub(Args, VarTypes, InstMap,
>  			InitialInsts, InstVarSub0), InstVarSub),
>  
> +		% Apply the inst_var substitution to the argument modes.
>  		{ mode_list_apply_substitution(ArgModes1, InstVarSub,
>  			ArgModes2) },
> +
> +		% Calculate the final insts of the argument variables
> +		% from their initial insts and the final insts of called
> +		% procedure (with inst_var substitutions applied.

That comment is missing a ')'.


Apart from that, this relative diff looks fine.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------



More information about the developers mailing list