[m-rev.] for review: delete see/seen/tell/told from io.m

[Peter Wang]

On Sat, 05 Mar 2022 04:43:51 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> In a thread on m-dev starting on 2021 august 23, we agreed to break up
> io.m, which is by far the biggest module in the system, after the next release.
> Since the release has now branched off, this diff implements the first step.
> 
> My proposals for what should be done with the rest of io.m, based mostly
> on the discussion then:
> 
> Set A: We could move see/seen/tell/told predicates to prolog.m.
> DONE
> 
> Set B: The predicates involving the reporting of offsets within files,
> and seeking to them. They are not needed in most cases, but I don't think
> it is worth moving them elsewhere.
> PROPOSAL (from julien): move them to wherever binary input/output preds end up
> 
> Set C: The predicates that open/read/write/close binary streams.
> I am slightly in favour of keeping these in io.m.
> PROPOSAL (from julien): move to four submodules, read/write x text/binary
> PROPOSAL: leave this decision until other moves done (when we know io.m's updated size)
> 

For me, reading and writing to streams is the core of io.m.
I'm not in favour of moving those predicates out. If io.m is still too
big, we could move the implementations to private submodules and forward
to them. Or move the foreign code to separate files and use the
include_file mechanism (if it works with mmake).

> Set D: I think we should move the predicates that read and write bitmaps
> to bitmap.m.
> PROPOSAL: move the code to bitmap.m now
> PROPOSAL (from julien): move the code to write arrays to array.m now; agreed
> PROPOSAL: leave io.write_list in io.m for now

Ok to all three.

> Set E: We could carve off the input_stream_fold* predicates. I am neutral
> about this.
> PROPOSAL: leave this decision until other moves done

PROPOSAL: deprecate and remove them eventually. At least, I don't think
they are really useful in practice. The few uses in the compiler
directory might be the only uses.

> 
> Set F: We could move everything in the "file handling predicates" section
> to a new module, maybe file.m or files.m. I think this would be good idea.
> PROPOSAL: move these to io.file.m now

Agreed.

> 
> Set G: We would move the predicates handling temp files, either to a separate
> temp_files.m module, or to file.m/files.m. I am in favour of the latter.
> PROPOSAL: move these to io.file.m now

Agreed.

> 
> Set H: We could carve off progname and command_line_args. I don't think
> this is worth it.
> PROPOSAL: leave in io.m

Agreed.

> 
> Set I: We should move the predicates handling environment vars to
> environment.m, as discussed.
> PROPOSAL: move them to io.environment.m now

I'm neutral on this. Could just leave them in io.m like progname and
command_line_args.

> 
> Set J: We could move the call_system* predicates to a new module, maybe
> call_system.m. I am neutral on this.
> PROPOSAL: move them to io.call_system.m now

Agreed.

> 
> Set K: We could move the predicates operating in the globals to a new
> module globals.m, if we didn't mind the name clash with compiler/globals.m.
> PROPOSAL: move them to io.globals.m now

PROPOSAL: deprecate and remove them

> 
> Set L: We should move the predicates printing stats to benchmarking.m
> (those that aren't there already).
> PROPOSAL: move them to benchmarking.m now

Agreed.

> When moving predicates from io.m to a new module (which I propose
> to do one or two of the above sets at a time), I intend to
> 
> - move the code,
> - fix whatever breaks in the rest of the system,
> - add forwarding predicates from io.m to the predicates' new home,
>   marking them as obsolete.
> 
> Adding the forwarding predicates last front-loads the task of updating
> code for me/us, while letting other users of Mercury choose when to
> switch.

All three steps should be in a single commit anyway, so that's fine.

Peter