[m-rev.] splitting io.m

[Zoltan Somogyi]

On Tue, 18 Aug 2015 11:14:11 +1000, Peter Wang <novalazy at gmail.com> wrote:
> The runtime itself is too hairy so I'd like to see stuff moved out,
> rather than in.  (The foreign include_file extension can help here. 
> If it existed then, I would have added the MR_utf8_* functions to the
> library and not the runtime.  string.m is also too big.)

This kind of complexity is like toothpaste: if you squeeze it out of
one place, it moves to another place. I think what matters is not
the location of this code, but its coupling to other parts of the system.
(I do agree it is easier to avoid unwanted coupling between files
that are in different directories.)

> I'm not interested a wide-ranging break of the io.m interface (even with
> a transition period), if that is what is proposed.  It would annoy me
> greatly as a user as it does not seem justified.

I don't think anything else would accomplish your objective of making
io.m easier to edit. If you moved a bunch of foreign procs to new
submodules, the stuff left behind would become easier to edit,
but the stuff you split up (interface here, implementation there)
would become *harder* to edit.

I agree that we shouldn't annoy users unnecessarily. That is the reason
why I haven't felt that breaking io.m into small pieces was worthwhile.

> - prolog-style see/seen/tell/told [1]
> - progname
> - command_line_arguments
> - exit_status
> - globals [1]
> - environment variables
> - make_temp
> - remove file, rename file, symlinks, file access, file type, file modtime
> - report_stats [2]
> - call_system
> 
> I would have no qualms about deprecating [1] and moving [2].

On that, I agree, though I think that before [1], we should remove
its uses from the compiler. (I have a workspace in which I am doing
just that for one use that I found baffling while working on the item list
change.)

I also would have no objection to moving some of those other groups,
e.g. temp files, env vars, call_system, command line, to other
modules. They aren't really about input or output, and the new modules
containing them would have reasonably high cohesion. However, since
these are small pieces of code, the vast majority of io.m would
still be left behind.

Zoltan.