[m-dev.] for review: use bitsets in quantification

[schachte at cs.mu.OZ.AU]

On  8 Nov, Fergus Henderson wrote:
> Actually on second thoughts I disagree with the idea too:
> sparse_bitset doesn't strictly require that `to_int' return contiguous
> values, but I can't see any practical advantage in defining `to_int'
> in a way that doesn't return contiguous values, and so I don't think
> this extra flexibility would actually buy you anything.

I was thinking of cases where you're using a C enum type (or a
psuedo-type defined with #defines) that has holes, and you want to use
that type directly in Mercury to avoid translation.  I've seen some such
types defined as powers of two specifically so you could make sets of
them -- wouldn't it be ironic if you couldn't use Mercury bitsets for
them?  (To make such types efficiently usable in bitsets, it might be a
good idea to make the predicate/function that maps between value and
the various needed masks be a method of this class.)

Let me turn the question around:  why do you want prev and next?  I
agree with the goal of keeping things simple.  In the absence of default
methods, having unneeded methods means having unneeded, distracting
code for every instance.  (I know this flies in the face of my
parenthetical comment at the end of the previous paragraph -- take this
as another reason why we really need default methods.)

-- 
Peter Schachte                     The use of COBOL cripples the mind; its
mailto:schachte at cs.mu.OZ.AU        teaching should, therefore, be regarded
http://www.cs.mu.oz.au/~schachte/  as a criminal offense.
PGP: finger schachte at 128.250.37.3      -- E. W. Dijkstra 

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