Proposal: add 'findLess' and variants to containers
Twan van Laarhoven
twanvl at gmail.com
Sat Feb 18 20:44:46 CET 2012
On 2012-02-18 00:51, Johan Tibell wrote:
> Lets settle on the names. I
> currently dislike that we have 'lookup' and 'findDefault' (which is
> lookup with a default value.) We should agree on a principle for when
> we use the two words.
With regards to 'lookup' vs 'find': the current convention seems to be that
lookup* returns 'Maybe a', while find* returns 'a'. Compare for example
'lookupIndex' and 'findIndex'.
That means that the proposed functions should be called 'lookupLess', etc.
On 2012-02-18 11:46, Milan Straka wrote:
> At some point I thought maybe we could add just these two functions:
> predecessor :: Ord a => a -> Set a -> Maybe a
> successor :: Ord a => a -> Set a -> Maybe a
> These functions work like findLess, findGreater, i.e., they return
> a strict predecessor or successor of a given key. The key does not need
> to exist in the set/map.
The terms successor and predecessor make some sense for Set, but less for a Map.
IMO, a name like findGreater makes the intent much clearer.
> Are there any good use cases for findLessEqual/findGreaterEqual,
> instead of calling lookup and if it fails, call predecessor/successor?
Such a two-tier lookup would be two times as slow, and also inconvenient for the
user of the library. With this argument we should also get rid of, for example,
one of 'isSubmapOf' and 'isProperSubmapOf'.
Here is a simple use case: suppose that you have some boxes, Set Size, and want
to find the smallest box that will fit a certain item. The natural thing to do
would be 'findGreaterEqual itemSize boxes'.
If the sizes are integers, you could do 'findGreater (itemSize-1) boxes'. But
that makes the intent of the code less clear, and makes it easier to introduce
bugs. This trick also fails when sizes are not integers.
More information about the Libraries