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

[Zoltan Somogyi]

On 02-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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.

No, it is not supposed work if you mix modules with special preds and modules
without special preds. However, there is no point in making this a grade option
as yet, for two reasons. First, --no-special-preds doesn't fully work at the
moment, due to comparisons on types with user-defined equality. Second, even if
it did work, using it would at the moment result in a slowdown. The only use
of the option at the moment is benchmarking.

I have thought about the splitting the option into two, one governing whether
special preds are generated and one governing whether they are assumed to exist
in other modules, but I couldn't find a good reason why one may want to use
them.

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

Enum types can have user-defined equality, but builtins can't. I have clarified
the log message.

> > +:- 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.

Actually, its meaning depends on higher_order.m's specialization capabilities,
and not on something that is inherent in special preds. I will therefore leave
it in higher_order.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.

I have done so; that was the model for this code. The differences are just
enough to make sharing the code unwieldy.

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

Just aesthetics. The old code was not part of the regression test.

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