[m-rev.] for review: decide type representations via checked type definitions

[Julien Fischer]

Hi Zoltan,

On Sat, 26 Oct 2019, Zoltan Somogyi wrote:

> For review by anyone.

> Decide simple representations using checked type definitions.
> 
> compiler/check_parse_tree_type_defns.m:
>     Change the definition of a checked type to distinguish direct_dummy
>     and enum types on the one hand, which may have foreign enum definitions,
>     from other du types, which may not.
>
>     Change the definition of a checked type to record the names of the
>     function symbols in direct_dummy and enum types, since type representation
>     items need this information, we have it, and requiring decide_type_repn.m
>     to compute it again from scratch is wasteful.
>
>     Do not explicitly record the number of function symbols in direct_dummy
>     % and enum types, and the number bits needed to represent values of

Delete "%".

>     such types. We now store the list of function symbols in such types,
>     and this information is trivially computable from that.
>
>     Check foreign enum definitions for correctness. At the moment,
>     this sort-of duplicates related functionality in add_foreign_enum.m,
>     but the intention is that eventually, these checks will be done only here,
>     with the sort-of duplicated code in add_foreign_enum.m being deleted there.

...

> diff --git a/compiler/check_parse_tree_type_defns.m b/compiler/check_parse_tree_type_defns.m
> index fdc1f851c..e301e6d99 100644
> --- a/compiler/check_parse_tree_type_defns.m
> +++ b/compiler/check_parse_tree_type_defns.m

...

> @@ -114,34 +114,46 @@

...

>
>                  % For each of our target foreign languages, this field
>                  % specifies whether we have either a foreign language
>                  % definition for this type, or a foreign enum definition.
> +                %
> +                % While the Mercury representation uses small integers
> +                % allocated consecutively from 0 to represent function symbols,
> +                % this is not true even for foreign enum definitions,
> +                % much less foreign type definitions.
>                  c_j_cs_e_maybe_defn_or_enum
>              )
> +    ;       std_mer_type_du_not_all_plain_constants(
> +                std_du_type_status,
> +
> +                % The discriminated union type definition, which represents
> +                % type *other* than a direct dummy type or an enum.

*a* type

> +                item_type_defn_info_du,
> +
> +                % For each of our target foreign languages, this field
> +                % specifies whether we have a foreign language type definition
> +                % for this type.
> +                c_j_cs_e_maybe_defn
> +            )
>      ;       std_mer_type_abstract(
>                  std_abs_type_status,
>

...


> @@ -204,7 +214,29 @@
>
>  :- type foreign_type_or_enum
>      --->    foreign_type_or_enum_type(item_type_defn_info_foreign)
> -    ;       foreign_type_or_enum_enum(item_foreign_enum_info).
> +    ;       foreign_type_or_enum_enum(checked_foreign_enum).
> +
> +    % Part of checking a foreign enum definition is checking whether
> +    % the corrrespondence it describes between the Mercury functors

One to many 'r's in correspondence there.

> +    % of the type on the one hand and their foreign language counterparts
> +    % on the other hand is a perfect bijection. If yes, then the second

Delete "perfect".

> +    % argument of the checked_foreign_enum we construct gives the foreign
> +    % language counterpart of each Mercury function symbol in the type in the
> +    % order in which the Mercury function symbols are defined.
> +    %
> +    % For example, given
> +    %
> +    %   :- type t ---> m1 ; m2 ; m3.
> +    %
> +    % and a foreign enum definition that gives the correspondence correctly
> +    % but in a different order, such as
> +    %
> +    %   :- pragma foreign_enum("C", t/0, [m2 - "f2", m3 - "f3", m1 - "f1"]).
> +    %
> +    % the second argument will contain the (nonempty) list "f1", "f2", "f3".
> +    %
> +:- type checked_foreign_enum
> +    --->    checked_foreign_enum(item_foreign_enum_info, one_or_more(string)).
>
>  %-----------------------------------------------------------------------------%
>  %-----------------------------------------------------------------------------%

...

> diff --git a/compiler/comp_unit_interface.m b/compiler/comp_unit_interface.m
> index 66cce7d62..c34ec6e37 100644
> --- a/compiler/comp_unit_interface.m
> +++ b/compiler/comp_unit_interface.m

...

> @@ -2571,6 +2524,16 @@ get_int2_items_from_int1_imp_types([ImpTypeDefn | ImpTypeDefns],
>
>  %---------------------%
> 
> +/*
> +    % Maps each type constructor in the module that has at least one
> +    % foreign_enum pragma for it to a list, each member of which says
> +    % "for this language, the functors of the type are implemented
> +    % by this string in that foreign language".
> +    %
> +:- type foreign_enum_map ==
> +    map(unqual_type_ctor,
> +        assoc_list(foreign_language, one_or_more(pair(sym_name, string)))).
> +

Why is this commented out code here?

>  :- pred record_foreign_enum_spec(item_foreign_enum_info::in,
>      foreign_enum_map::in, foreign_enum_map::out) is det.
> 
> @@ -2586,6 +2549,7 @@ record_foreign_enum_spec(ForeignEnumInfo, !ForeignEnumTypeCtors) :-
>          map.det_insert(UnqualTypeCtor, [Lang - OoMValues],
>              !ForeignEnumTypeCtors)
>      ).
> +*/

...

> diff --git a/compiler/prog_item.m b/compiler/prog_item.m
> index 34b6ec44f..e30057741 100644
> --- a/compiler/prog_item.m
> +++ b/compiler/prog_item.m

...

> @@ -1326,112 +1328,137 @@
>  % Information about the representations of types defined in other modules.
>  %
>

...

> +    % - Only the last four of the function symbols of this type are
> +    %   now intended to be the used. The others are part of a discarded
> +    %   attempt to redesign that ancient system.
> +    %   XXX TYPE_REPN Delete the others.
> +    %
> +    % - Only this type needs to contain representation information.
> +    %   A value of the type_ctor_checked_defn type needs to contain *part*
> +    %   of the information from which this representation information is
> +    %   computed for its type, but not *all* of it; some of that information
> +    %   comes frin information about the representation of *other* types.

s/frin/from/

The diff looks ok otherwise.

Julien.