[m-rev.] Solver support for abstract equivalence solver types

[Julien Fischer]

On Wed, 1 Dec 2004, Ralph Becket wrote:

> Zoltan Somogyi, Friday, 19 November 2004:
> >
> > Otherwise the diff is fine.
>
> Unfortunately it wasn't: it's taken me nearly two weeks to hunt down
> these bugs!
>
> Here's the LOG and relative diff:
>
>
> Estimated hours taken: 140
> Branches: main
>
> Extend the solver types implementation to handle abstract equivalence solver
> types.
>
> Fix the automatic initialisation of solver type variables to work for atomic
> goals.
>
> compiler/goal_util.m:
> 	Add a version of goal_util__generate_unsafe_cast with two
> 	extra inst parameters (needed because solver types
> 	typically have inst any rather than ground).
>
> compiler/make_hlds.m:
> 	Fixed a bug whereby the declarations for special preds for imported
> 	types were being module qualified using the name of the *importing*
> 	module.  This turns out to be correct for unification and comparison
> 	predicates because they are duplicated in every module that needs
> 	them, but not for solver type initialisation predicates.
>
> compiler/modes.m:
> 	Export modes__construct_initialisation_call which is now
> 	also called from unify_proc.m.
>
> 	Fix a misleading compiler error message.
>
> 	Rearrange some comments for accuracy.
>
> 	Scheduling of conjunctions now handles the mode_info flag
> 	may_initialise_solver_vars slightly differently to support the
> 	initialisation of free solver vars in atomic goals not appearing
> 	in conjunctions.
>
> 	construct_initialisation_call(s) and prepend_initialisation_call now
> 	change the mode_info (and thus does not need the module_info).
>
> 	construct_initialisation_call and build_call are now much more
> 	careful about setting up goal_infos, vartypes and instmap_deltas
> 	correctly.
>
> compiler/modecheck_call.m:
> 	Ensure that modecheck_end_of_call properly restores the
> 	mode_info may_initialise_solver_vars flag before returning.
>
> compiler/modecheck_unify.m:
> 	Arrange for one of the solver vars to be initialised in free/free
> 	unifications if mode_info_may_initialise_solver_vars is set.
>
> 	XXX Var/functor unification still needs fixing.
>
> compiler/mode_info.m:
> 	Added mode_info_get_may_initialise_solver_vars.
> 	mode_infos are now initialised to have the may_initialise_solver_vars
> 	flag set to yes in order to allow the initialisation of solver type
> 	goals not appearing in conjunctions.  Conjunctions temporarily set
> 	this flag to no to try scheduling without inserting initialisation
> 	calls.
>
> compiler/polymorphism.m:
> 	Add new exported pred, process_new_call.  This predicate takes
> 	the details about a call to be inserted somewhere after the
> 	usual polymorphism pass has been run and extends the call with
> 	the goals and extra arguments to construct and pass any
> 	required type_infos.
>
> compiler/type_util.m:
> 	A type that is equivalent to a solver type is now also considered
> 	a solver type.
>
> compiler/unify_proc.m:
> 	The compiler generated initialisation predicate for an abstract
> 	equivalence solver type first calls the initialisation predicate
> 	for the RHS of the type equivalence, then casts the result back
> 	into the type on the LHS of the type equivalence.
>

Are there any tests cases that exercise the above bug fixes or do
the existing tests cover them adequately?

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