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

[Zoltan Somogyi]

2022-03-05 12:26 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> 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.

Agreed; the proposal to move them out was Julien's.

> If io.m is still too
> big, we could move the implementations to private submodules and forward
> to them

Agreed. That is exactly the kind of detail it should be easier to evaluate later.

I think what we will probably end up doing is splitting up the implementations
of the predicates in question along the lines proposed by Julien, while leaving
their declarations exactly where they are now.

>> 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.

Will do.

>> 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.

I have never used them and have not looked at them recently, so I have
no opinion on the matter right now.

>> 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.

Will do all of these.

>> 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.

Both these sets of predicates are reasonably small, so moving them does not
reduce file size *that* much, but they are also rarely used, so moving them
would speed up the compilation of modules that import I/O (by reducing
the cost of reading in the declarations).

>> 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.

Will do.

>> 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

I am not sure what you mean: deprecating a predicate is meaningful only
if you leave it in place.
 
>> 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.

Will do.

>> 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.

Exactly.

There is another issue that I came across while updating the NEWS file
for this diff. In the section for changes to the Mercury library, we list
all the predicates deletes and/or moved. That's fine. The question is,
should we list them all *also* in the section for changes that may break
compatibility, or should the entry for that section be merely something
that points readers to the affected modules in the library section.
The update to the NEWS file in the attached diff was the part I was
most expecting feedback on.

Peter, did you review the diff, or did you just reply to the body of
my email?

Zoltan.