getRange behavior when index has several values for each entry

[JPMoresmau]

Hello, I have this (simplified) example taken from the code docs :

data Entry      = Entry Content
   deriving (Show, Eq, Ord, Data, Typeable)
newtype Content = Content String
   deriving (Show, Eq, Ord, Data, Typeable)
newtype CWord = CWord String
   deriving (Show, Eq, Ord)

getWords :: Entry -> [CWord]
getWords (Entry (Content s)) = map CWord $ words s

type EntryIxs = '[CWord]
instance Indexable EntryIxs Entry where
     indices = ixList
                 (ixFun getWords)

type IxEntry = IxSet EntryIxs Entry

The key here is that one Entry can give several CWord

Then if I do:

let entries  = insertList [Entry (Content "word1 word4")] (empty :: IxEntry)
let r = getRange (CWord "word2") (CWord "word3") entries

I would have expected r to be empty, since no word in my only Entry is between word2 inclusive and word3. However, r does contain my Entry. I suppose, having looked at the result for getLT and getGTE, than since the entry matches LT (with word1) and GTE (with word4), it is returned, even though the matches are on different values!

If that's normal behavior, is there an easy way to code a range query that checks the range applies on each value independently of the others?

Thanks!

[kosmikus]

Interesting. Thanks for the report.

Personally, I'm tempted to call this a bug. However, when I created ixset-typed, I just took ixset and provided a more strongly typed interface on top of it. I just verified that ixset behaves the same on this example, so it's not a "regression" introduced by ixset-typed.

I don't currently see an easy way to achieve what you want, but I agree that your expectation seems more natural and more useful in practice, although I currently don't know how tricky it would be to implement.

Perhaps @stepcut has some additional background information regarding the current design?

[srid]

There appears to be a fix in this PR #4