[m-dev.] for review: improvements to type specialization [1]

[David Glen JEFFERY]

On 30-Sep-1999, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> Estimated hours taken: 50
> 
> Remove the limitation of user-guided type specialization that
> the replacement types must be ground.
> 
> compiler/higher_order.m:
> 	Only add extra type-infos, not typeclass-infos when
> 	--typeinfo-liveness is set, extracting type-infos from
> 	typeclass-infos where necessary. This avoids the need to
> 	work out how to order any extra typeclass-infos, and
> 	maximises the chance of multiple specialized calls to the same
> 	procedure being able to use the same code.

I'm a little confused by this... perhaps you could elaborate here or in
the code. What is so hard about working out what order the typeclass infos
go in?

> 
> 	Specialize special preds for no-tag types where the
> 	wrapped type is an atomic type and the no-tag type does not
> 	have a user-defined equality pred. This will be useful
> 	for specializations involving type `term__var/1'.
> 
> 	Make sure the proc_infos for specialized procedures are
> 	valid before reanalyzing the goals requesting the
> 	specializations.
> 
> 	Rework the handling of branched goals to ensure that pred_infos
> 	and proc_infos are single threaded through branched goals - when
> 	higher_order.m was first written they were constant.
> 
> 	Always go over all procedures for every predicate to make
> 	sure unifications are specialized in all procedures.
> 
> compiler/make_hlds.m:
> 	Check for type variables substituted multiple times
> 	or occurring on both sides of the substitution.
> 
> 	Adjust the arity for specializations of functions.
> 
> compiler/polymorphism.m:
> 	Make sure the vartypes field for imported procedures is valid
> 	by copying it from the clauses_info to the proc_info.
> 
> compiler/polymorphism.m:
> compiler/simplify.m:
> compiler/table_gen.m:
> compiler/magic.m:
> 	Remove an unused argument from polymorphism__make_type_info_vars.
> 
> compiler/type_util.m:
> compiler/det_analysis.m:
> 	Add a predicate `type_util__type_has_user_defined_equality_pred'
> 	replacing similar code in det_analysis.m.
> 
> compiler/post_typecheck:
> 	Don't overwrite the vartypes field in the pred_info for
> 	automatically generated unification procedures for imported types.
> 
> library/varset.m:
> 	Add predicates `varset__merge_without_names' and
> 	`varset__merge_subst_without_names'.
> 	
> compiler/equiv_type.m:
> 	Use the new predicates in varset.m to avoid adding the variable
> 	names from the declarations of equivalence types into the tvarsets
> 	of declarations which use those types. This is needed so that
> 	`varset__create_name_var_map' is not confused by multiple occurrences
> 	of a variable name.

It would be helpful if you mentioned why varset__create_name_var_map is
needed. (ie. because you match the name of the tvar in the pragma decl
with that in the type decl).

> doc/reference_manual.texi:
> 	Remove documentation of the limitation that the substituted types
> 	must be ground.
> 
> tests/hard_coded/type_spec.m:
> tests/hard_coded/type_spec.err_exp:
> 	Tests for non-ground substitutions and specialization of
> 	unification of no-tag types.
> 
> tests/invalid/type_spec.err_exp:
> 	Remove the error for a non-ground substitution.
> 	Add tests for recursive type substitutions and type variables
> 	with multiple replacement types.

> Index: compiler/higher_order.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/higher_order.m,v
> retrieving revision 1.55
> diff -u -u -r1.55 higher_order.m
> --- higher_order.m	1999/09/21 07:03:48	1.55
> +++ higher_order.m	1999/09/30 01:39:23

> +traverse_goal_0 -->
> +	{ MustRecompute = no },
> +	traverse_goal_0(MustRecompute).

The use of the name `traverse_goal_0' is a bit weird here. It seems to me
that the traverse_goal_0 is the pred used from the outside, and traverse_goal
is used internally by it... wouldn't traverse_goal and traverse_goal_2 be
better names? (Mind you, that's fairly picky).
> +	% WARNING - do not filter out higher-order arguments after this step,
> +	% except when partially matching against a previously produced
> +	% specialization, otherwise some type-infos that the call
> +	% specialization code is expecting to come from the curried
> +	% arguments of the higher-order arguments will not be present
> +	% in the specialized argument list.

Does this comment deserve to go above the head of the predicate, as part of
the documentation of its interface?

> +		% for imported types, and Tyson has been talking for ages
> +		% about doing generic unification and comparison in C code in
> +		% the runtime system. 

...and Zoltan has just posted a diff which implements most of that.

[ I haven't spotted anything else wrong with your changes to higher_order.m, 
but I'm not at all familiar with this code, so that's not too surprising ].



dgj
-- 
David Jeffery (dgj at cs.mu.oz.au) | If your thesis is utterly vacuous
PhD student,                    | Use first-order predicate calculus.
Dept. of Comp. Sci. & Soft. Eng.|     With sufficient formality
The University of Melbourne     |     The sheerist banality
Australia                       | Will be hailed by the critics: "Miraculous!"
                                |     -- Anon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------