[m-rev.] splitting io.m

Peter Wang novalazy at gmail.com
Mon Aug 17 17:29:28 AEST 2015


On Mon, 17 Aug 2015 17:02:55 +1000, Paul Bone <paul at bone.id.au> wrote:
> On Mon, Aug 17, 2015 at 04:43:55PM +1000, Peter Wang wrote:
> > Hi,
> > 
> > Would there be any opposition to splitting io.m into multiple modules,
> > while maintaining the interface?  Most of the predicates have the
> > exported Mercury predicate wrapping private foreign_procs.  I'm thinking
> > the foreign_procs can be moved into submodules.  The submodules might be
> 
> I've also considered splitting up IO.
> 
> I started with moving file and directory handling stuff into dir.m.  There
> is definitely some scope overlap between io.m and dir.m both doing filesystem
> things.

I think dir.m should have been restricted to manipulating path and
filenames in the abstract.  Filesystem handling should have been in a
separate module.  I'm not intending to break any interfaces (not for
this, anyway).

> >     io.error
> >     io.read
> >     io.write
> >     io.seek
> >     io.file_type
> >     io.rename
> >     io.file_time
> >     io.environ
> >     io.system
> >     io.make_temp
> >     ...
> 
> This is more finer-grained than I would have chosen.  Also I was going to
> move all things, not just the foreign code, into the other
> modules/submodules.

If we move a user-visible predicate to a submodule then we would need to
add a forwarding predicate to maintain the io.m interface.  When a
top-level predicate is fairly trivial (many of them are) it seems it
might as well act as the forwarding predicate itself.

Peter



More information about the reviews mailing list