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

[Julien Fischer]

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.

Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------