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

[Julien Fischer]

On Fri, 8 Dec 2006, Mark Brown wrote:

> On 08-Dec-2006, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> 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.
>
> Aside from the fact that for constructors there are no universal type_infos
> or typeclass_infos, what's the difference?

You've just stated it.

> The point is that if the calling
> convention is changed in future (e.g., so that type_infos are always passed
> as separate arguments) then the same sort of change will need to be done for
> constructor arguments as for procedure arguments.

I'm not opposing the idea; just saying that we should use a separate
data structure for a separate (albeit) related task.

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