[m-rev.] for post-commit review: var_name_print and output_lang

[Julien Fischer]

Hi Zoltan,

On Fri, 27 Mar 2020, Zoltan Somogyi wrote:

> This diff adds only comments, so I am mostly looking for reviews
> of the substance of those comments, though there may be issues
> with the spelling/grammar as well.

...

> diff --git a/compiler/prog_data.m b/compiler/prog_data.m
> index a759e3d8a..ba844a911 100644
> --- a/compiler/prog_data.m
> +++ b/compiler/prog_data.m

...

> +    % This situation can be fixed in one (or both) of two ways.
> +    %
> +    % - The first way is to simplify change the convention for the names
> +    %   of type_info variables in foreign_procs. We could have an interim
> +    %   period where, if the relevant type signature contains type variables
> +    %   named e.g. K and V, in that order, then the type type_info for K
> +    %   would be available in *two* variables, named TypeInfo_for_K and
> +    %   TypeInfo_for_V_1, and similarly the type_info for V would be available
> +    %   in TypeInfo_for_V and TypeInfo_for_V_2. People could replace code
> +    %   that uses the first of these with code using the second, then
> +    %   we could stop defining the old variable names, and then we would be
> +    %   free of the compulsion to use print_name_only for all those item types
> +    %   listed above.
> +    %
> +    % - The second way is to change the compiler so that when matching
> +    %   variables from two different varsets that both represent the same
> +    %   conceptual signature, such as the signature of a predicate, we do
> +    %   so using variable numbers, not using variable names.
> +    %
> +    % The first seems easier.

Agreed, the first seem easier. I note that how type_info variables are
passed into foreign_procs is not documented in the reference manual, so
this is not a user facing issue anyway. (In the extremely rare cases
where users want to access a type_info in a foreign_proc, I think they
should be encouraged to get that type_info using type_of/1 and pass it
to the foreign_proc as a normal argument.)

Julien.