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

Julien Fischer juliensf at csse.unimelb.edu.au
Thu Dec 7 15:46:27 AEDT 2006


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.

     % This type is a structure representation of some property of the
     % arguments of a procedure or class method.
     %
:- 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.

                 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.

                 pa_univ_typeclass_infos :: list(T),
                 % Typeclass_infos for universally quantified constraints
                 % in the order that the constraints appear in the class
                 % context.

                 pa_exist_typeclass_infos :: list(T),
                 % Typeclass_infos for existentially quantified constraints
                 % in the order that the constraints appear in the class
                 % context.

                 pa_orig_args :: list(T),
                 % The original procedure arguments.

                 pa_maybe_ret_value :: maybe(T)
                 % For predicates this field is no; for functions it
                 % corresponds to the return value.
             ).

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



More information about the developers mailing list