[m-rev.] splitting io.m

[Peter Wang]

On Mon, 17 Aug 2015 17:48:39 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> As for me, I *would* object to putting the declaration of a
> user-facing predicate and its implementation in different files, at least
> if it is done on a long-term basis, because it would represent avoidable
> coupling between the files. I also don't think you would gain all that much
> (in terms of the size of io.m) by it. In many cases, the declaration
> is as big as the implementation, because of the comments on it.

We can add the forwarding predicates then.

> We *could* divide up the documented interface of io.m into groups
> of related predicates (which io.m already does, sort-of), and decide
> to put each group of predicates into a module of its own. These groups
> could include
> 
> - predicates that read from text files (including putback)
> - predicates that read from binary files (ditto, if needed)
> - same two groups for writes
> - predicates that open/close files
> - predicates that implement the old prolog-style see/seen/tell/told
>   interface
> - predicates that invoke system, environ etc
> 
> We could move both the declarations and the implementations
> of these predicates into the new modules (which need NOT be
> submodules of io.m), and leave a forwarding predicate for each
> in io.m, with an obsolete pragma.
> 
> We would probably need to move the definitions of the C types
> currently in foreign_decl pragmas to the runtime, to allow them
> to be accessed from the new modules. 

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

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 after
the whole exercise our programs would be particularly improved.

Aside from the main functionality of reading/writing/opening/closing
files, there are also:

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

Peter