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

[Julien Fischer]

On Thu, 7 Dec 2006, Mark Brown wrote:

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

Yes.  (replacing those in clauses_info was a given anyway since the
polymorphism pass operates on it.)

> You may also want to replace the cons_args field of hlds_cons_defn, since
> these also have extra arguments added.

I don't think that replacing it with this is correct since what we're
replacing it with here corresponds to the arguments of procedures not
type constructors; we can do something similar for that field though.

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

arg_pass_info for one.

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

Okay.

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

Jerome posted one such transformation the other day :-)

I think that argument origin information should be even finer grained
than what is in this data structure (which is really just intended
for catching violations of invariants required by the calling
convention).  Argument origin information should also record things like
exactly what transformation added an argument.  Adding such origin information
is a separate change though.

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