[m-dev.] from [mercury-users] Re: Question regarding determinism

[Peter Schachte]

On Fri, Sep 18, 1998 at 06:01:42PM +1000, Fergus Henderson wrote:
> If mode inference is to work, then mode analysis has to be done top-down
> (at least unless you change the mode analysis algorithm drastically).
> The reason for this is that the initial insts for a procedure are not
> known until you've analysed at least one of the calls to that procedure.
> 
> Determinism analysis should as you say be done bottom-up, for efficiency.
> 
> This is a good argument for keeping these two phases separate ;-)

Not as good an argument as you might think.  You can still do them
together if the analysis is a dependency analysis.  First you compute,
bottom-up, which modes are possible for each predicate and what the
determinism would be for that mode, without committing to generating
code for any particular mode.  You want a representation for the set
of possible modes other than a simple list, something along the lines
of

	if X and Y are ground, then Z will be too, and the spine of
	either X or Z must be determined at call time; if the spine of
	X is determined on call, the call is at worst semidet; if at
	one of X and Z are free on call, the call is det

would describe append/3.  In the second (top-down) phase, you
determine which modes are actually used and do the goal scheduling.
Even when there are pred and mode declarations, this approach would
allow you not to generate code for unused modes, and probably even
infer undeclared uniqueness.  If you delay code generation until a
third (bottom-up) phase, you can do specialization as you generate
code (this observation due to Zoltan).

If you continue to require full type and mode declarations for
exported predicates and functions, this can all be done a module at a
time.


-- 
Peter Schachte                | To understand reality, try to change it.
mailto:pets at cs.mu.OZ.AU       |     -- Henry Volken, Jesuit activist 
http://www.cs.mu.oz.au/~pets/ | 
PGP: finger pets at 128.250.37.3 |