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

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

On Tue, 9 Nov 2010, Julien Fischer wrote:

> 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
> predicates.
> So long as the library reference manual is consistent w.r.t these
> matters I'm not terribly fussed by the ordering.

The above was actually meant to be a reply to the other thread
concerning the coding standard.

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