[m-rev.] diff: cleanup, and question for fjh or dmo

[Zoltan Somogyi]

This is a cleanup diff; there are no changes in algorithms.

compiler/delay_info.m:
compiler/instmap.m:
compiler/inst_match.m:
compiler/inst_util.m:
compiler/make.module_target.m:
compiler/mode_errors.m:
compiler/modes.m:
compiler/mode_util.m:
compiler/process_util.m:
compiler/prog_io_goal.m:
compiler/prog_io.m:
compiler/prog_io_pragma.m:
compiler/prog_io_typeclass.m:
compiler/recompilation.check.m:
compiler/recompilation.m:
compiler/recompilation.usage.m:
compiler/recompilation.version.m:
compiler/unique_modes.m:
	Bring these modules up to date with our current style guidelines.
	Switch to predmode syntax and state variable notation where
	appropriate. Switch argument orders where this makes it possible
	to use state variable notation. Use the svmap and svset modules
	where appropriate. Fix inconsistent indentation; in some places,
	fix inconsistent placement of comments.

compiler/passes_aux.m:
compiler/modecheck_unify.m:
compiler/mercury_compile.m:
compiler/post_typecheck.m:
compiler/prog_io_dcg.m:
compiler/mode_ordering.m:
compiler/inst_graph.m:
compiler/polymorphism.m:
compiler/prog_io_util.m:
compiler/mode_debug.m:
compiler/mode_robdd.check.m:
compiler/transform.m:
	Minor changes to conform to the changed argument orders of some
	predicates in the cleaned up modules. Also, some minor cleanups.

The diff is excruciatingly boring as well as very big, so I won't post
it here; anyone who is interested can find it in ~zs/tmp/DIFF.cleanup.

The one bit that is interesting is in inst_util.m, in the first clause
for abstractly_unify_inst. The two lines marked with *** below show that
ModuleInfo0 is accessed even after ModuleInfo0 is updated to ModuleInfo1.
I have preserved the existing behavior, but I would like to know whether
anyone (especially Fergus or David) knows whether this is a bug, a
deliberate but undocumented decision, or simply a choice that doesn't
matter.

Zoltan.

abstractly_unify_inst(Live, InstA, InstB, UnifyIsReal, ModuleInfo0,
			Inst, Det, ModuleInfo) :-
		% check whether this pair of insts is already in
		% the unify_insts table
	ThisInstPair = unify_inst(Live, InstA, InstB, UnifyIsReal),
	module_info_insts(ModuleInfo0, InstTable0),
	inst_table_get_unify_insts(InstTable0, UnifyInsts0),
	( map__search(UnifyInsts0, ThisInstPair, Result) ->
		( Result = known(UnifyInst, UnifyDet) ->
			Inst0 = UnifyInst,
			Det = UnifyDet
		;
			Inst0 = defined_inst(ThisInstPair),
				% It's ok to assume that the unification is
				% deterministic here, because the only time that
				% this will happen is when we get to the
				% recursive case for a recursively defined inst.
				% If the unification as a whole is semidet then
				% it must be semidet somewhere else too.
			Det = det
		),
		ModuleInfo = ModuleInfo0,
		Inst1 = Inst0
	;
			% insert ThisInstPair into the table with value
			% `unknown'
		map__det_insert(UnifyInsts0, ThisInstPair, unknown,
			UnifyInsts1),
		inst_table_set_unify_insts(UnifyInsts1, InstTable0, InstTable1),
***		module_info_set_insts(InstTable1, ModuleInfo0, ModuleInfo1),
			% unify the insts
***		inst_expand(ModuleInfo0, InstA, InstA2),
		inst_expand(ModuleInfo0, InstB, InstB2),
		abstractly_unify_inst_2(Live, InstA2, InstB2, UnifyIsReal,
			ModuleInfo1, Inst0, Det, ModuleInfo2),

			% If this unification cannot possible succeed,
			% the correct inst is not_reached.
		( determinism_components(Det, _, at_most_zero) ->
			Inst1 = not_reached
		;
			Inst1 = Inst0
		),

			% now update the value associated with ThisInstPair
		module_info_insts(ModuleInfo2, InstTable2),
		inst_table_get_unify_insts(InstTable2, UnifyInsts2),
		map__det_update(UnifyInsts2, ThisInstPair, known(Inst1, Det),
			UnifyInsts),
		inst_table_set_unify_insts(UnifyInsts, InstTable2, InstTable),
		module_info_set_insts(InstTable, ModuleInfo2, ModuleInfo)
	),
		% avoid expanding recursive insts
	( inst_contains_instname(Inst1, ModuleInfo, ThisInstPair) ->
		Inst = defined_inst(ThisInstPair)
	;
		Inst = Inst1
	).
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------