[m-dev.] call for volunteers: get_environment_var_map

[Zoltan Somogyi]

On Tue, 24 Aug 2021 00:32:00 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > 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.

I presume you mean  moving the one actual implementation to prolog.m,
and leaving a deprecated forwarding predicate in io.m.

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

That works. I presume you intend for us to add similar seek/offset predicates
next to the predicates that manipulate text files, if we ever add code
to seek on text input or output files?

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

That looks appealing, but you have to consider where stdin_stream,
stdout_stream and stderr_stream go. The above scheme would
split them between io.text_{in,out}put, especially if the types
{text,binary}_{in,out}put_stream go in the submodules,
but arguably, splitting them would violate the law of least astonishment.
I think the types, and these three preds, should remain in io.m
itself.

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

I agree that like bitmap, writing arrays and lists could be moved
to array.m and list.m, but I think writing builtin types should stay in io.m.
 
> > 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?

I am the wrong person to ask: I don't think I have ever used these I/O fold
predicates either in io.m or in stream.m.

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

Then we are in agreement on this.

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

OK.

Should I move the code getting the complete environment from
the compiler to io.m, or do you still intend to do that yourself?
 
> > 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.

Agreed.

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

We should keep the I/O globals for backward compatibility, even if
we deprecate the predicates that operate on it.
 
Zoltan.