[m-dev.] for review: removing --args simple

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon May 31 15:03:36 AEST 1999


> >  	{ hlds_pred__define_new_pred(Goal, CallGoal, HeadVars, ExtraArgs,
> >  		InstMap, PredName, TVarSet, VarTypes, ClassContext, TVarMap,
> > -		TCVarMap, VarSet, Markers, Owner,
> > +		TCVarMap, VarSet, Markers, Owner, no,
> >  		ModuleInfo1, ModuleInfo2, LocalPredProcId) },
> 
> I'd suggest adding a separate unification `HasAddressTaken = no', or adding
> `:- type address_taken ---> address_taken ; address_not_taken'.
> (There are more instances of this elsewhere).

OK, I'll add the type.

> >  	/* no more iterations */
> > -	count_output = framevar(3);
> > -	time_output = MR_get_user_cpu_miliseconds() - framevar(4);
> > +	r1 = framevar(3);
> > +	r2 = MR_get_user_cpu_miliseconds() - framevar(4);
> >  	succeed_discard();
> 
> I think these changes (and similar changes throughout the library
> and runtime) make the code less readable.

I thought about that. You are right, replacing symbolic names with
register numbers reduces readability. However, since we are using the
same registers for both input and output, anyone who maintains such code
*must* be aware of the need not to overwrite registers containing inputs
while those inputs are still needed. If they don't, the result is a
very subtle bug. Using register numbers explicitly will force maintainers
to think about this issue.

Given that the Mercury declaration of the procedure being implemented in C
is usually (almost always) close by to provide the mapping from registers
to variable names, I think I chose the lesser of the two available evils.

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