[m-rev.] for review: stop using .tmp files when writing .intN files

[Julien Fischer]

On Mon, 12 Feb 2024, Zoltan Somogyi wrote:

> Stop using .tmp files when generating .intN files.
> 
> compiler/write_module_interface_files.m:
>     Instead of
>
>         - writing out the new version of a .intN file to module.intN.tmp,
>         - comparing that file with module.intN, and
>         - renaming module.intN.tmp to module.intN if they differ,
>
>     we now
>
>         - read in the old .intN file to a string
>         - convert the new parse tree for .intN to a string
>         - write out the string form of the new parse tree to module.intN
>           if they differ.
>
>     The logic is bit more complex in the presence of smart recompilation
>     (in both the old new algorithms) but not by much.
>
>     The new algorithm requires significantly fewer system calls than the old.
> 
> compiler/comp_unit_interface.m:
>     Don't create a name for .intN.tmp files, since they are not needed anymore.
> 
> compiler/module_cmds.m:
>     Reorder the predicates that copy files putting the most basic predicate
>     last, so that calls go from earlier predicates to later predicates.
> 
> compiler/parse_module.m:
>     Delete unneeded IO state args from the parse_intN_file predicates.
> 
> compiler/parse_tree_out.m:
>     Carve output_parse_tree_string out of the existing
>     output_some_parse_tree predicate which also *constructed* that parse tree.
>     This capability is needed by new code in write_module_interface_files.m,
>     which wants to perform other operations on the string forms of parse trees
>     before writing them out.

...

> %---------------------------------------------------------------------------%
> %
> % The following three predicates operate on parse_tree_int0s, parse_tree_int1s
> % and parse_tree_int2s. They do exactly the same thing with all three,
> % so their codes are identical, except for the fact that
> %
> % - they operate on values of different types, and
> % - they call predicates that perform the same operations on those different
> %   types.

That seems to be the situation that type classes are intended to address.
I guess in this case defining an appropriate class and its associated instances
would be more verbose than having three almost copies?

The diff looks fine.

Julien.