[m-rev.] splitting io.m

Peter Wang novalazy at gmail.com
Wed Aug 19 11:03:28 AEST 2015


On Tue, 18 Aug 2015 14:34:32 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > 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.

Understood.  Let's not do it the way I had suggested.

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

Small pieces each, but they add up.  Apart from the above, the stream db
and buffer code are also recognisable subsystems that could be moved out
of the way.  I also think the main foreign_code blocks would be better
off included from separate files.

But now I'm going to get comfortable with vim code folding, or find
another editor.

Peter



More information about the reviews mailing list