[m-dev.] more module dependency issues

[Fergus Henderson]

As part of my work on introducing a new back-end, I've been analyzing
the intermodule dependencies in the existing compiler.  I've identified
a number of places where front-end modules (e.g. hlds*.m) have dependencies
on back-end modules (e.g. rl*.m, llds*.m), or where one of the two current
major back-ends (llds*.m) has dependencies on the other (rl*.m).

I would like to try to eliminate or at least reduce these dependencies.
Eventually, we might even want to move the different major components
of the compiler into separate sub-directories.

The following discusses the dependencies in details and outlines some
possible solutions.  I'd appreciate any feedback.

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

hlds_module.m:
mlds.m:
	- depend on some types used for the C interface (`pragma import'
	  and `pragma export') which are currently defined in llds.
	
	solution: move those types into a new module (e.g. c_code.m
	or foreign_code.m).

hlds_data.m:
hlds_goal.m:
hlds_out.m:
hlds_pred.m:
	- import llds.m for code_model, which is used only
          in the predicates hlds_data:determinism_to_code_model,
          goal_info_get_code_model, hlds_out__write_code_model,
	  proc_info_interface_code_model, and
	  hlds_pred:valid_code_model_for_eval_method.

	solution: move those predicates elsewhere (e.g. code_model.m),
	except perhaps for hlds_out__write_code_model, which could just
	be deleted, since it is never used,
	and for hlds_pred:valid_code_model_for_eval_method, which should
	be rewritten based on determinism and/or can_fail.

hlds_pred.m:
hlds_goal.m:
hlds_out.m:
	- The various hlds annotations
		stack_slots (in the proc_info),
	  	follow_vars (in the goal_info),
	  	and store_map (in the hlds_goal_expr for branched goals)
	  all reference the llds `lval' type.

	  possible solution: parameterize the hlds types (ugh!)
	  possible solution: use univ (inefficient -- intolerably so?)
	  possible semi-solution:
	  	Move the annotation types into a seperate module called say
		hlds_annotations.m and make them discriminated unions:
			:- type proc_annotation
				--->	none
				;	llds(llds_proc_annotation)
				;	mlds(mlds_proc_annotation)
				;	other(univ).
		That is still a little inefficient, but tolerably so.
		That solves the extensibility problem, but leaves the
		dependency in there.  To minimize the damage from the
		dependency, keep this module small and keep its interface
		abstract so that it can easily be modified or replaced.

bytecode.m:
bytecode_gen.m:
	- use llds.m.  Don't yet know why.

unique_modes.m:
	- uses code_model (via goal_info_get_code_model) == model_non

	solution: ought to use determinism (via goal_info_get_determinism)
	and soln_count (via determinism_components) == at_most_many.

llds_out.m:
	- Uses rl_file.m.

	solution: generalize llds.m to take higher-order preds for
	outputting extra arbitrary C code, rather than taking
	a maybe(rl_file).  Call these from mercury_compile.m
	(or rl_compile.m -- see below).

mercury_compile.m:
	Imports everything.  That is OK, though, because this is the
	top-level module.  Nothing imports mercury_compile.m.
	
	However, we should perhaps split parts of it into new modules
	llds_compile, rl_compile.m, and mlds_compile.m, for each of the
	major back-ends.  mercury_compile.m itself would then just
	contain the argument processing, front-end, and linking.

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