[m-dev.] for review: more RTTI restructuring

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Apr 14 14:37:45 AEST 2000


On 14-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> +:- pred code_util__make_proc_label_from_rtti(rtti_proc_label, proc_label).
> +:- mode code_util__make_proc_label_from_rtti(in, out) is det.
> +
> +code_util__make_proc_label_from_rtti(RttiProcLabel, ProcLabel) :-
> +	RttiProcLabel = rtti_proc_label(PredOrFunc, ThisModule,
> +		PredModule, PredName, Arity, ArgTypes, _PredId, ProcId,
> +		IsImported, _IsPseudoImported, _IsExported),
>  	(
> -		code_util__compiler_generated(PredInfo)
> +		special_pred_name_arity(_, _, PredName, Arity)
>  	->

I don't like this change. Using a predicate's name and arity to decide
whether it is compiler generated or not has always been a bad one:
vulnerable to false positives (from determined lunatics, granted),
and losing information (e.g. in HLDS dumps) about *which* __Unify__ or
__Compare__ predicate is meant.

I think it would be a good idea to limit the number of places affected by
this design decision, so that we can change it more easily in the future.
In this case, that would mean extending rtti_proc_label with a bool saying
whether the procedure is from a compiler-generated pred, and using that bool,
both here and in ml_code_util.m.

> +:- type rtti_proc_label
> +	--->	rtti_proc_label(
> +			pred_or_func		::	pred_or_func,
> +			this_module		::	module_name,
> +			pred_module		::	module_name,
> +			pred_name		::	string,
> +			arity			::	arity,
> +			arg_types		::	list(type),
> +			pred_id			::	pred_id,
> +			proc_id			::	proc_id,
> +			is_imported		::	bool,
> +			is_pseudo_imported	::	bool,
> +			is_exported		::	bool
> +		).

Document the reasons for storing these bools instead of the import_status.

Apart from these concerns, the diff is fine.

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



More information about the developers mailing list