[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