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

Fergus Henderson fjh at cs.mu.OZ.AU
Sun Apr 16 01:59:56 AEST 2000


On 14-Apr-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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.

OK.

This particular piece of code is not actually deciding whether the
predicate was compiler generated (in the general sense) or not,
it is deciding whether the predicate is a special_pred or not, in order to
determine whether to generate a `pred' label or a `special_pred' label.
So calling `special_pred_name_arity' directly, rather than via
code_util__compiler_generated, is a more self-documenting way
of writing this code that more directly expresses what it is doing.

But the problem there is really that code_util__compiler_generated
is poorly named (not to mention undocumented).
Originally the name was reasonable, but now there are other kinds
of compiler generated predicates, and code_util__compiler_generated
only tests for one kind.

So I'll add a new bool field to rtti_proc_label, but the name of the field
will be `is_special_pred' rather than `is_compiler_generated'.

We should rename code_util__compiler_generated, but I'll leave that
one for a separate change.

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

Shall do.

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