[m-dev.] for dicussion: more structured procedure arguments

[Mark Brown]

I agree with this proposal.  One advantage it will bring is that polymorphism
will no longer need two passes -- it currently needs two passes so it doesn't
get confused over which arguments it has already introduced.

On 07-Dec-2006, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> 
> At the moment we represent procedure arguments as lists of things, where
> things are prog_vars, modes, types etc.  There is an implicit structure to
> these lists, e.g. type_infos for universally quantified type variables must
> come before those for existentially quantified ones.  (see comments at the
> head of compiler/polymorphism.m.) This is easily breakable and makes making
> modifications to the way the polymorphism pass works or changing the calling
> convention quite difficult.
> 
> An improvement would be use a data structure that makes the structure of the
> arguments explicit instead of using lists.  Below is one such data
> structure.  I am proposing that we use this structure (or something 
> similar) to replace some of the fields in the proc_info and proc_sub_info,
> e.g. head_vars and actual_head_modes.

Also replace fields in hlds_goal_expr and clauses_info, since polymorphism.m
would otherwise have to assume a particular calling convention for them.
You may also want to replace the cons_args field of hlds_cons_defn, since
these also have extra arguments added.

What field(s) of proc_sub_info would need to change?

> 
>     % This type is a structure representation of some property of the
>     % arguments of a procedure or class method.

How about:

	% This type represents the arguments to a predicate symbol, or the
	% arguments and result of a function symbol.  The arguments may be
	% variables, types, modes, etc, depending on the context.
	%
	% Rather than keep all arguments in a single list, we retain
	% information about the origin of each argument (such as whether
	% it was introduced by polymorphism.m to hold a type_info).  This
	% simplifies the processing in polymorphism.m, and also abstracts
	% away the specific calling convention we use.

While we're at it, are there transformations other than polymorphism.m which
change the argument lists, and which would also benefit from having the
argument origin retained by this data structure?

>     %
> :- type proc_args(T)
>     --->    proc_args(
>                 pa_instance_typeinfos :: list(T),
>                 % Type_infos for unconstrained type variables in the
>                 % instance declaration.  For procedures that are not
>                 % class methods this will always be the empty list.
> 
>                 pa_instance_typeclass_infos :: list(T),
>                 % Typeclass_infos for the class constraints on the instance
>                 % declaration; in the order that they appear in the
>                 % declaration.  For procedures that are not class methods
>                 % this will always be the empty list.
> 
>                 pa_univ_type_infos :: list(T),
>                 % Type_infos for universally quantified type variables,
>                 % in the order that type variables first appear in the
>                 % argument types.

For our current scheme, this should read "for _unconstrained_ universally
quantified type variables".  The comment in polymorphism.m gets this wrong,
I've just noticed.

> 
>                 pa_exist_type_infos :: list(T),
>                 % Type_infos for existentially quantified type variables,
>                 % in the order that the type variables first appear in
>                 % the argument types.

Similarly here.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------