[m-dev.] call for volunteers: get_environment_var_map

[Zoltan Somogyi]

On Thu, 19 Aug 2021 00:27:47 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > > I think environment.m.  Should that be a top-level module in the library
> > > or a submodule of the io module?
> > 
> > I don't think we should decide that for environment.m alone. We should
> > decide along what lines we want to break up io.m, and use the nature
> > of fragments to help answer that question.
> 
> Absolutely.

I see several possible sets of predicates to split off from io.m.
I list them in the order in which they appear in io.m.

Set A: We could move see/seen/tell/told predicates to prolog.m.
I am neutral on this. The point in its favor is that it would emphasize
the fact that new code should not use these. The point against,
which is applicable to all these sets, is of course is its negative
impact on backwards compatility.

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.

Set C: The predicates the open/read/write/close binary streams.
I am slightly in favour of keeping these in io.m.

Set D: I think we should move the predicates that read and write bitmaps
to bitmap.m.

Set E: We could carve off the input_stream_fold* predicates. I am neutral
about this.

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.

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.

Set H: We could carve off progname and command_line_args. I don't think
this is worth it.

Set I: We should move the predicates handling environment vars to
environment.m, as discussed.

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

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.

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

What we do with the predicates exported by io.m whose declarations
do NOT go into the manual is much less important, since backwards
compatility is not really a concern for these.

Based on the above, I think that with the exception of the parts
that we should move to bitmap.m or benchmarking.m, and maybe prolog.m,
any parts we carve off into new modules are still mainly about I/O, so the
new modules should be submodules of io.m.

Opinions?

Zoltan.