[m-dev.] call for volunteers: get_environment_var_map

[Julien Fischer]

Hi Zoltan,

On Mon, 23 Aug 2021, Zoltan Somogyi wrote:

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

Some initial thoughts.

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

I am in favour of this change and despite me saying that restructuring
of the io module should wait until after the next release, I think we
could deprecate the versions of these operations in io.m and add
replacements to prolog.m now.

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

These belong with the other predicates that manipulate binary files
(wherever they happen to end up).

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

File I/O splits up naturally along a couple of axes input / output and
text / binary.  You could have a divsion along either, or both, of those
axes.  Given that predicates for handling file I/O make up the bulk of
the io module, I would be inclined to split along each axis and push
those predicates into submodules of io:

     io.text_input
     io.text_output
     io.binary_input
     io.binary_output

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

That would seem to also be a case for:

     io.write_array --> array module
     io.write_list  --> list module
     io.write_int   --> int module
     io.write_char  --> char module

etc etc.

For the sake of consistency I think it ought to be one or the other.

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

Another option is to simply deprecate and eventually delete them since
there are more general versions of these operations available in
stream.m.

Another issue: the result types in the stream module are slightly more
general versions of those in the io module (for the most part); do we
need both?

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

I propose we move everything file "related" which isn't actually reading
from or writing to files into io.file.

(That submodule would also have the new file_time type I suggested in
Mantis #536 added to it.)

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

Agreed.  I think those two and also the predicates for dealing with
the exit status should stay where they are.

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

I think these should be moved too.

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

If (as you suggest below) it becomes a submodule (e.g. io.globals) then
the clash is unimportant since as AFAIK the compiler doesn't use the I/O
globals anymore.

Do we even need the I/O globals given that the language has mutables?
(Mutables don't currently have an equivalent of io.update_globals/3.)

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

Agreed, the new modules should be submodules of io.m.

Julien.