[m-dev.] for review: counter.m

[Fergus Henderson]

On 09-Mar-2000, Robert Ernst Johann JESCHOFNIK <rejj at students.cs.mu.oz.au> wrote:
> On Thu, 9 Mar 2000, Zoltan Somogyi wrote:
> 
> > +	% counter__allocate(N, Counter0, Counter) takes a counter, and
> > +	% returns (a) the next integer to be allocated from that counter,
> > +	% and (b) the updated state of the counter.
> > +:- pred counter__allocate(int::out, counter::in, counter::out) is det.
> 
> Wouldn't it make more sense for a counter to be a unique object? Or at
> least allow for it to be unique? It may be desirable to ensure that one
> never uses an old value of a counter..

Simplying _allowing_ a counter to be unique would not achieve that effect;
if you want to _ensure_ that the old value of a counter is never used,
then you need to _require_ counters to be unique.

But in many situations where you might want to use counters,
it would not be possible to require them to be unique.
There is definitely a need for a non-unique counter type.

We could add a different type called say `unique_counter',
which had a different interface that required it to be unique.
But until we support nested unique modes, that would most
likely cause more problems than it solves.  So for now I
think we should stick with using an interface that does not
use unique modes.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------