[m-rev.] splitting io.m

[Paul Bone]

On Mon, Aug 17, 2015 at 05:29:28PM +1000, Peter Wang wrote:
> 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.
> 

Yeah, that makes sense.  I guess the decision is are we deprecating/changing
the io.m interface?  I know you're not proposing it in this change but maybe
in the future.


-- 
Paul Bone