[m-rev.] proposed changes to set modules in stdlib

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Nov 9 11:39:06 AEDT 2010

On Tue, 9 Nov 2010, Peter Wang wrote:

> On 2010-11-09, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> Hi,
>> Based on Peter's table here is a set of proposed changes to the various
>> set modules in the stdlib with the aim of unifying their interfaces.
>> We can probably get away with breaking backwards compatibility
>> for all of them except for set.m / svset.m (so I've done that).
>> Also, where there are predicate and function versions of an operation
>> I've only retained the predicate version where it is useful with
>> state variables.
> I usually reach for a predicate first, then get told off by the
> compiler.  The conventional function form breaks the left-to-right flow
> in Mercury code: inputs on the left, outputs on the right.  I'm often
> tempted to write `f(A, B, C) = R' instead.

IIRC, the rationale for the ordering was that the function version of an
operation typically only has a single mode whereas the predicate
versions often have many modes.  Quite often this lead to the function
declaration being "lost" amongst the mode declarations for the

So long as the library reference manual is consistent w.r.t these
matters I'm not terribly fussed by the ordering.

mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au

More information about the reviews mailing list