[m-rev.] for post-commit review: use maps in interface file parse trees

[Julien Fischer]

On Thu, 12 Sep 2019, Zoltan Somogyi wrote:

> For post-commit review by Julien, since he has read and approved
> the proposal for this.

> Use maps to several kinds of items in interface file parse trees.

...

> diff --git a/compiler/prog_item.m b/compiler/prog_item.m
> index a29ad87..b340033 100644
> --- a/compiler/prog_item.m
> +++ b/compiler/prog_item.m

...

> @@ -311,29 +315,129 @@
>                  pti3_imported_modules       :: set(module_name),
>
>                  % Items of various kinds in the interface.
> -                pti3_type_defns             :: list(item_type_defn_info),
> -                pti3_inst_defns             :: list(item_inst_defn_info),
> -                pti3_mode_defns             :: list(item_mode_defn_info),
> +                pti3_type_defns             :: type_ctor_defn_map,
> +                pti3_inst_defns             :: inst_ctor_defn_map,
> +                pti3_mode_defns             :: mode_ctor_defn_map,
>                  pti3_typeclasses            :: list(item_typeclass_info),
>                  pti3_instances              :: list(item_instance_info),
> -                pti3_type_repns             :: list(item_type_repn_info)
> +                pti3_type_repns             :: type_ctor_repn_map
>              ).
> 
> -:- type parse_tree_opt
> -    --->    parse_tree_opt(
> -                pto_module_name             :: module_name,
> -                pto_opt_file_kind           :: opt_file_kind,
> +%-----------------------------------------------------------------------------%
> +%
> +% The intended semantics of a type_ctor_defn_map is a map of
> +% all the type constructors defined in a given SECTION of a given
> +% interface file to all its definitions in that section.
> +%
> +% There are four intended uses of a type_ctor_defn_map. The most
> +% important is the fourth one.
> +%
> +% One is to eliminate unnecessary items from interface files.
> +% For example, library/set.m contains two definitions of the set
> +% type constructor: an abstract definition in the publicly documented
> +% interface section, and an actual du definition in another interface
> +% section that we do not include in the automatically generated
> +% documentation but we *do* export to other modules. In situations
> +% like this, the abstract definition is redundant. Never including it
> +% in an interface file lets that interface file to remain unchanged
> +% in the event that the user deletes the abstract definition from
> +% the source file as well.
> +%
> +% The second use is to canonicalize the parts of interface files
> +% containing type definitions.
> +%
> +% The third use is to help deal with sets of definitions make sense.

That sentence doesn't make sense.

> +% There are many rules that a set of definitions for a given type
> +% constructor must meet (such as "there may be at most one definition
> +% for a type constructor that is a du, equivalence or solver definition),
> +% and bugs may manifest themselves as violations of these rules.

The rest looks fine.

Julien.