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

[Zoltan Somogyi]

On Sun, 29 Mar 2020 03:23:33 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> On Fri, 27 Mar 2020, Zoltan Somogyi wrote:
> > +    % - 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.)

This diff is stage 1 of implementing the first approach by making it
possible to update the names of variables holding compiler-generated
type_infos in foreign_procs to a new naming scheme in which names
such as TypeInfo_for_<typevarname> are replaced with names such as
TypeInfo_{In,Out}_<seqnum>. Once this diff is installed, I will update
the foreign_procs (stage 2), and once *that* is all done, I will replace
this workaround (stage 3).

This diff has passed bootcheck in hlc.gc and asm_fast.gc. I am bootchecking
it in grade java now; it has just started the tests. An earlier version has
bootchecked in the csharp grade with 69 unexpected failures, which is
par for the course (in other words, they are actually expected :-);
I will repeat the bootcheck with the current version before commit.
And of course I have visually checked the generated code for small
test cases both for the usual case of input type_infos, and for code like
type_desc.has_type, in which the type_info is output. I have also
checked that the compiler will do the right thing on that small
test case even after the foreign_proc switches to using the new
naming scheme, though a full test of that functionality is not
possible before this diff has been installed.

Julien, could I ask you to review this?

Zoltan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.fpti
Type: application/octet-stream
Size: 2643 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200408/86306d12/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.fpti
Type: application/octet-stream
Size: 32750 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200408/86306d12/attachment-0003.obj>