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

[Mark Brown]

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

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

That's what I was about to suggest.

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

Fair enough.

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