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

[Julien Fischer]

Hi,

On Sat, 5 Mar 2022, Peter Wang wrote:

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

I'm fine with leaving the stream predicates as-is until the rest is done
and the reconsidering the matter.

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

Leaving io.write_list in the io module while the corresponding write
predicates for other data types are moved to their respective modules
is inconsistent.

In the 2021-08-23 thread, it was suggested that the io module continue
to handle primitive types and all the others be moved.

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

The stream module contains generic versions of the input_stream_foldl
predicates anyway; as Peter said, the io versions are rarely used, so we
may as well deprecate the io module versions and direct users to the
stream module versions.

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

I support moving environment handling to a separate submodule.
At the very least, the existence of io.environment should make it more
obvious to users where the envionment handling predicates live.

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

As Peter mentioned further in this thread, the the role of io.globals is
now (mostly) subsumed by mutables.  The latter are usually better anyway
as they don't require packing things inside a univ.

The one place where io.globals provides functionality that mutables do
not is allowing atomic updates, via io.update_globals/3. It was always
intended that mutables be extended to support that as well; once that
exists I think we can deprecate and (eventually) remove the io globals.

Julien.