[m-dev.] for review: reordering for existential types [1]

[Fergus Henderson]

On 16-Jun-1999, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> On 11-Jun-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Change the order of the passes so that polymorphism comes before
> > mode analysis.  This is necessary so that mode analysis can properly
> > reorder code involving existential types.
> 
> When this gets merged onto the main branch, you will probably want a bit more
> of an explanation here about what this diff is actually trying to achieve.

OK, shall do.

> > +++ hlds_goal.m	1999/06/10 14:11:30
> > @@ -310,7 +310,19 @@
> >  
> >  	;	complicated_unify(
> >  			uni_mode,	% The mode of the unification.
> > -			can_fail	% Whether or not it could possibly fail
> > +			can_fail,	% Whether or not it could possibly fail
> > +			list(prog_var)	% The type_info variables needed
> > +					% by this unification, if ends up
> 
> s/if ends/if it ends/
> 
> BTW, it isn't that obvious why a complicated unification would require type
> infos, so you might like to explain this further somewhere.

OK.  See the diff below.

 	% A unify_context describes the location in the original source
> > +lambda__process_module(ModuleInfo0, ModuleInfo) :-
> > +	module_info_predids(ModuleInfo0, PredIds),
> > +	lambda__process_preds(PredIds, ModuleInfo0, ModuleInfo1),
> > +	% Need update the dependency graph to include the lambda predicates. 
> > +	module_info_clobber_dependency_info(ModuleInfo1, ModuleInfo).
> 
> I assume that by clobbering the dependency graph, some later pass fills it
> in again. Is that right?

Yes.  Later passes will call module_info_ensure_dependency_info, which
will recompute it if it has been clobbered.

> > lambda.m:
> > +	% Calculate the constraints which apply to this lambda
> > +	% expression. 
> > +	% Note currently we only allow lambda expressions
> > +	% expression.  
> > +	map__keys(TCVarMap, AllConstraints),
> > +	map__apply_to_list(Vars, VarTypes, LambdaVarTypes),
> > +	list__map(type_util__vars, LambdaVarTypes, LambdaTypeVarsList),
> > +	list__condense(LambdaTypeVarsList, LambdaTypeVars),
> > +	list__filter(lambda__constraint_contains_vars(LambdaTypeVars), 
> > +		AllConstraints, UnivConstraints),
> > +	Constraints = constraints(UnivConstraints, []),
> 
> This is conservative, right? This will give you all the constraints on the
> variables in the lambda expression, regardless of whether the constraints
> are generated inside or outside the expression.

Hmm.  That is a subtle point.  I think there might be a bug there.
I'll have to think about it a bit more.

However, all my change did is to move this code from polymorphism.m
to lambda.m.  If there is a bug in that code, then it is a bug
which already exists in the current compiler.  So I'll address that
one seperately from my existential types changes.

--------------------

Estimated hours taken: 0.1

compiler/hlds_goal.m:
	Improve some comments, as suggested by dgj's code review.

Index: hlds_goal.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/hlds_goal.m,v
retrieving revision 1.59.2.1
diff -u -u -r1.59.2.1 hlds_goal.m
--- hlds_goal.m	1999/06/10 16:10:21	1.59.2.1
+++ hlds_goal.m	1999/06/23 03:16:44
@@ -311,18 +311,28 @@
 	;	complicated_unify(
 			uni_mode,	% The mode of the unification.
 			can_fail,	% Whether or not it could possibly fail
+
+			% When unifying polymorphic types such as
+			% map/2, we need to pass type_info variables
+			% to the unification procedure for map/2
+			% so that it knows how to unify the
+			% polymorphically typed components of the
+			% data structure.  Likewise for comparison
+			% predicates.
+			% This field records which type_info variables
+			% we will need.
+			% This field is set by polymorphism.m.
+			% It is used by quantification.m
+			% when recomputing the nonlocals.
+			% It is also used by modecheck_unify.m,
+			% which checks that the type_info
+			% variables needed are all ground.
+			% It is also checked by simplify.m when
+			% it converts complicated unifications
+			% into procedure calls.
 			list(prog_var)	% The type_info variables needed
-					% by this unification, if ends up
+					% by this unification, if it ends up
 					% being a complicated unify.
-					% This field is set by polymorphism.m.
-					% It is used by quantification.m
-					% when recomputing the nonlocals.
-					% It is also used by modecheck_unify.m,
-					% which checks that the type_info
-					% variables needed are all ground.
-					% It is also checked by simplify.m when
-					% it converts complicated unifications
-					% into procedure calls.
 		).
 
-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------