[m-dev.] for review: --no-special-preds

Fergus Henderson fjh at cs.mu.OZ.AU
Sun Apr 2 03:59:43 AEST 2000


A general issue: is the `--no-special-preds' option supposed
to be one that you can use different settings of when compiling
different modules which will then be linked into a single
executable?  If so, then there are several places in the code
(in higher_order.m and simplify.m) which do not handle things correctly.
 If not, then the `--no-special-preds' option should be a grade option and
should thus be included in the mangled grade string and handled specially by
the code in the various files listed in runtime/mercury_grade.h.

On 31-Mar-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> comparison/polymorphism.m:
>         Fix a bug: the code for looking up the special preds for user defined
>         types was handling enums as builtins, which they are not.

Well, the code there was handling enums _in the same way as_ builtins.
While it's clear that enums are not builtins, it would be helpful to
explain why they can't be handled the same.

> Index: compiler/higher_order.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/higher_order.m,v
> retrieving revision 1.62
> diff -u -b -r1.62 higher_order.m
> --- compiler/higher_order.m	2000/03/24 10:27:26	1.62
> +++ compiler/higher_order.m	2000/03/30 07:43:30
> @@ -1623,21 +1626,77 @@
>  	),
>  
>  	(
> -		SpecialId = unify,
> +		% Look for unification or comparison applied directly to
> +		% a builtin or atomic type. This needs to be done separately
> +		% from the case for user-defined types, because we want to
> +		% specialize such calls even if we are not generating any
> +		% special preds.
> +
> +		specializeable_special_call(SpecialId, CalledProc),
>  		type_is_atomic(SpecialPredType, ModuleInfo),

Hmm, I don't understand why this case needs to be done separately.
Couldn't the condition of the if-then-else be a disjunction,
e.g.

		( specializeable_special_call(SpecialId, CalledProc),
  		  type_is_atomic(SpecialPredType, ModuleInfo)
		;
		  HaveSpecialPreds = yes
		)

?  
(Quite there is some reason why that won't work, but the
comment there doesn't say why, which makes that comment
more mystifying than enlightening, IMHO.)

> +:- pred specializeable_special_call(special_pred_id::in, proc_id::in)
> +	is semidet.
> +
> +specializeable_special_call(SpecialId, CalledProc) :-
> +	proc_id_to_int(CalledProc, CalledProcInt),
> +	(
> +		SpecialId = unify,
> +		CalledProcInt = 0
> +	;
> +		% compare has four procedures numbered 0 to 3 with identical
> +		% behavior, whose two input arguments' modes are all the
> +		% possible combinations of (ui,in) with (ui,in).
> +		SpecialId = compare,
> +		CalledProcInt =< 3
> +	).

That predicate should probably go in special_pred.m.

> +:- pred generate_unsafe_type_cast(module_info::in, (type)::in,
> +	prog_var::in, prog_var::out, hlds_goal::out,
> +	proc_info::in, proc_info::out) is det.
> +
> +generate_unsafe_type_cast(ModuleInfo, ToType, Arg, CastArg, Goal,
> +		ProcInfo0, ProcInfo) :-
> +	module_info_get_predicate_table(ModuleInfo, PredicateTable),
> +	mercury_private_builtin_module(MercuryBuiltin),
> +	(
> +		predicate_table_search_pred_m_n_a(PredicateTable,
> +			MercuryBuiltin, "unsafe_type_cast", 2, [PredIdPrime])
> +	->
> +		PredId = PredIdPrime
> +	;
> +		error("generate_unsafe_type_cast: pred table lookup failed")
> +	),
> +	proc_id_to_int(ProcId, 0),
> +	proc_info_create_var_from_type(ProcInfo0, ToType, CastArg, ProcInfo),
> +	set__list_to_set([Arg, CastArg], NonLocals),
> +	instmap_delta_from_assoc_list([CastArg - ground(shared, no)],
> +		InstMapDelta),
> +	goal_info_init(NonLocals, InstMapDelta, det, GoalInfo),
> +	Goal = call(PredId, ProcId, [Arg, CastArg], not_builtin,
> +		no, qualified(MercuryBuiltin, "unsafe_type_cast")) - GoalInfo.

It might be better to use `hlds_pred__initial_proc_id(ProcId)'
rather than `proc_id_to_int(ProcId, 0)'.

Some of this code is quite similar to unify_proc__build_call;
it would be worth having a glance at that and seeing if you
could reuse that code, if you haven't already done so.

simplify.m:
> @@ -1188,45 +1166,100 @@
>  		simplify__goal_2(Call0, GoalInfo0, Call1, GoalInfo),
>  		{ Call = Call1 - GoalInfo },
>  		{ ExtraGoals = [] }
> -
> -	; { type_to_type_id(Type, TypeId, TypeArgs) } ->
> +	;
> +		{ type_to_type_id(Type, TypeIdPrime, TypeArgsPrime) ->
> +			TypeId = TypeIdPrime,
> +			TypeArgs = TypeArgsPrime
> +		;
> +			error("simplify: type_to_type_id failed")
> +		},
> +		{ determinism_components(Det, CanFail, at_most_one) },
> +		{ unify_proc__lookup_mode_num(ModuleInfo, TypeId, UniMode, Det,
> +			ProcId) },
> +		{ module_info_globals(ModuleInfo, Globals) },
> +		{ globals__lookup_bool_option(Globals, special_preds,
> +			SpecialPreds) },
> +		(
> +			{ SpecialPreds = no },
> +			{ proc_id_to_int(ProcId, ProcIdInt) },
> +			{ ProcIdInt = 0 }
> +		->

This is one of the places where you are assuming that
the setting of the special_preds option in one module
implies something about the existence of special predicates
in a different module.

Also the test for the magic number zero here should be replaced by
a call to `hlds_pred__in_in_unification_proc_id(ProcId)'.

> +++ tests/hard_coded/user_defined_equality.m	2000/03/31 01:36:28
...
> @@ -18,7 +29,39 @@
>  
>  main -->
>  	( { append([bar], [baz], [baz, bar]) } ->
> -		print("yes"), nl
> +		io__write_string("yes\n")
>  	;
> -		print("no"), nl
> +		io__write_string("no\n")
> +	),

Any particular reason for that change (print, nl ==> io__write_string)?
In general it is better to leave regression tests unchanged where possible.

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