[m-dev.] proposed breakup of std_util.m

Ian MacLarty maclarty at cs.mu.OZ.AU
Thu Mar 23 19:08:33 AEDT 2006


On 3/22/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
>
> On Wed, 22 Mar 2006, Ian MacLarty wrote:
>
> > > That leaves std_util.m with:
> > >
> > >         * the unit type.
> > >         * generic higher-order operations like compose and converse.
> >
> > If this is all that's left then perhaps 'misc' would be a better name
> > than 'std_util' :-)  Perhaps these predicates should also be moved to
> > their own modules?
>
> I don't like the name 'misc', I prefer 'std_util' (or perhaps even just
> 'util').
>

I wasn't actually proposing to rename it to "misc", just that "misc"
seems like a better name now.  I think they should be broken up into
the two modules Ralph suggests.

> > I'm not opposed to the proposed changes, but I do feel we should,
> > where possible, first pragma obsolete predicates we intend to remove
> > for one numbered release and then remove them in the following
> > release, not just suddenly remove them.
>
> For the first of the changes, moving solutions, that can be done.  For
> the 0.13 release you'll need to module qualify calls to solutions in
> modules that import both std_util and solutions.   That should be too
> onerous though since calls to solutions are relatively rare.
>

But if you break what's left of std util as Ralph and I suggested then
you won't ever have to import std_util and any of the new modules at
the same time, so you can leave forwarding predicates in std_util (for
all the predicates) until 0.14, at which point you can completely
remove std_util.

> For moving semidet_fail etc to builtin, it's really not worth the bother of
> leaving forwarding predicates in place.
>

Why's it not worth it?  It's hardly any work and you won't any
ambiguity problems if you break up what's left in std_util.

Ian.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list