[m-dev.] for review: inference of mostly_unique modes

Andrew Bromage bromage at cs.mu.oz.au
Mon Jan 5 16:50:06 AEDT 1998


G'day.

You (Fergus Henderson) wrote:

> Andrew Bromage, I guess you're the other expert on modes --
> can you please review this one?

Sure.

I'm unhappy about overloading the unify_requests structure in this way.
You probably should rename it to reflect its new role.

Which reminds me: you may wish to fix some documentation rot in
hlds_module.m.  The documentation for module_info_get_unify_requests
says:

<<
	% For an explanation of the unify_requests structure,
	% see unify_info.m.
>>

As far as I can remember, we never had a unify_info.m module.

> Handle inference of unique (not just mostly-unique) modes.

I think you got those two around the wrong way.

> +	%
> +	% create the new procedure, set its "can-process" flag to `no',
> +	% and insert it into the queue of requested procedures.
> +	%
> +	unify_proc__request_proc(PredId, Modes, yes(ArgLives), MaybeDet,
> +		Context, ModuleInfo0, ProcId, ModuleInfo),

Where's the "can-process" flag, and where is the "no"?

> +
> +	% analyze everything with the "can-process" flag set to `yes'

s/with/which has/

I first parsed this as meaning that there was some kind of global
"can-process" flag.

> Index: tests/valid/mostly_uniq_mode_inf.m
> ===================================================================
[...]
> -p :- foo(42, Z), bar(Z, A), A > 100.
> +p :- foo(42, Z), ( baz(Z, B), bar(B, A), A > 100 ; Z > 100 ).

Could I suggest rather than changing an existing test, adding a new
one instead?  It's kinda unlikely that any code will break the first
and not the second, but these tests happen to be cheap and it can't
hurt.

Apart from that, it looks good.  Thanks, Fergus.

Cheers,
Andrew Bromage



More information about the developers mailing list