[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