[m-dev.] for review: type specialisation

[Fergus Henderson]

On 30-Aug-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> Rework the handling of types in higher_order.m.
> - Fix bugs in higher_order.m that stopped it working with --typeinfo-liveness.
> - Perform type and typeclass specialisation.

> compiler/polymorphism.m:
> 	Previously the type of typeclass_infos variables did not contain
> 	any information about the constraint about which the variable contains
> 	information. Now the type of a typeclass_info is
> 	`private_builtin:typeclass_info(
> 		private_builtin:constraint([ClassName, ConstrainedTypes]))'.
> 	This allows predicates such as type_list_subsumes to check that
> 	the class constraints match.
> 	Note that `private_builtin:constraint' has no declaration, so
> 	a lookup in the type definition map will fail. That's OK, because
> 	type_to_type_id will fail on it, so it will be treated as a type
> 	variable by any code which doesn't manipulate types directly.
> 	Added polymorphism__typeclass_info_class_constraint to get the
> 	class_constraint from a typeclass_info's type. This isn't used yet.
> 	In extract_type_info, an entry in the type_info_var_map
> 	was being overwritten using an entry from a dummy typevarset.

Does the last sentence describe a change unrelated to the other stuff?
If so, it would be helpful to seperate it a bit more clearly in the
log message, e.g. make it a new paragraph and insert "Also, fix a bug: "
at the start.

> compiler/higher_order.m:
...
> 	Specialize calls to unify/2, index/2 and compare/3.
> 	Specialize class_method_calls.
> 	Interpret the predicates in private_builtin.m which manipulate
> 	typeclass_infos.

"Interpret" is a bit unclear here.  Do you mean "Specialize calls to"?
If so, I think that way of phrasing it would be clearer.

The role of higher_order.m seems to be a bit more general now.
Perhaps higher_order.m should be renamed specialize.m?

> Index: compiler/higher_order.m
> +:- pred specialize_higher_order(bool::in, bool::in,
> +                module_info::in, module_info::out,
> +                io__state::di, io__state::uo) is det.

You should document the meaning of the `bool' arguments here.

> +traverse_goal_0(Goal0, Goal, Info0, Info) :-
> +        Info0 = info(_, B, NewPreds0, PredProcId, E, F, G, H, I),
> +        NewPreds0 = new_preds(_, PredVarMap),
> +        % Lookup the initial known bindings of the variables if this
> +        % procedure is a specialised version..

s/.././  ?

> @@ -586,63 +653,67 @@
>          ;
>                  error("higher_order.m: call expected")
>          ),
> -        module_info_pred_info(Module, CalledPred, PredInfo),
> +        module_info_pred_info(Module, CalledPred, CalleePredInfo),
>          (
> -                pred_info_is_imported(PredInfo)
> +                % Look for calls to unify/2 and compare/3 which can
> +                % be specialized.
> +                specialize_builtin(Info0, CalledPred, CalledProc,
> +                        Args0, MaybeContext, Goal1) 

The predicates unify/2, compare/3, and index are generally called
"special preds" rather than "builtins", so I suggest `specialize_builtin'
be renamed `specialize_special_pred'.

> +        % Interpret a call to `type_info_from_typeclass_info' or
> +        % `superclass_from_typeclass_info'. Currently they both have
> +        % the same definition. This should be kept in sync with
> +        % compiler/polymorphism.m and runtime/mercury_type_info.h.
> +:- pred interpret_typeclass_info_manipulator(typeclass_info_manipulator::in,

You should put comments in both of those places too,
saying that they should be kept in sync with this.

[... to be continued.]

> -:- pred filter_requests(module_info::in, set(request)::in, goal_sizes::in,

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