[m-rev.] For review: new constraint based mode analysis

[Zoltan Somogyi]

On 08-Feb-2005, David Overton <dmo at cs.mu.OZ.AU> wrote:
> > compiler/new_mode_constraints.m
> 
> This is not a good name for the module, since it presumably won't be new
> for long.

How about prop_mode_constraints?

> Please clarify what you mean here: is the user of this module not
> permitted to use a conj constructor that is not a child of a disj?  If
> so, you could enforce this through the type system, e.g:
> 
> 	:- type constraint_formula
> 		--->	atomic_constraint(var_constraint)
> 		;	disj(list(conj_formula)).
> 
> 	:- type conj_formula
> 		--->	constraint_formula(constraint_formula)
> 		;	conj(constraint_formulae).

I second the request for a clarification, though the types proposed above
aren't right.

> > +goal_expr_constraints(_ModuleInfo, _VarMap, _PredID,
> > +	switch(_, _, _), _GoalPath, _Nonlocals, _Constraints) :-
> > +	error("build_mode_constraints.m: "
> > +		++ "sorry, switch not implemented.").
> 
> Switches are not created until after mode analysis so no problem
> throwing an exception here.  However, if you want to be able to rerun
> mode analysis after switch detection then you could just treat a switch
> the same as a disjuntion.

Except that the switch has an implicit  unification at the start of each
arm.

> > +		),	% XXX type_info args should be at the start and
> > +			% should be 'in' so that is what this predicate adds
> > +			% however, I am not happy with it.
> 
> Why?

Because it isn't a robust technique. However, for now, it is the best we can
do.

> Parallel conjuncts must be independent and must produce the same set of
> variables, so this will look quite similar to the constraint for a
> disjuntion.

Parallel conjuncts must produce *disjoint* sets of variables. In fact,
no conjunct in a parallel conjunction may produce any variable that is
nonlocal to any of the other conjucts, at least with the current notion
of parallel conjuncts.

> Apart from the above comments, this all looke fine to me.  You've done a
> good job.

I second that.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------