[m-dev.] call for volunteers: get_environment_var_map

[Julien Fischer]

On Tue, 24 Aug 2021, Zoltan Somogyi wrote:

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

You presume correctly.

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

I suppose so. I don't recall anyone ever proposing to add those
operations on text 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.

The types may have to remain in io.m anyway; the way they are defined
for C# and Java may require that.  (I would need to take a look at it
to refresh my memory.)

...

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

Neither have I (and I'm fairly sure I wrote the ones in stream.m.)

...

> Should I move the code getting the complete environment from
> the compiler to io.m, or do you still intend to do that yourself?

I will do it.

Julien.