Thanks for taking the time to reply. I wrote up another post expanding upon the approach that you suggest.

Here’s a slight variation I thought of which solves these problems. Define a special list type that looks like this:

data StutterList a = Nil | Cons a (StutterList a) | AtLeast a (StutterList a)

The value (Cons x xs) of course tells you that the first element in the list is x, and the remaining elements are given by xs. Since we’re dealing with sorted lists we also know that all the elements of xs are at least x. The value (AtLeast x xs), on the other hand, just says that all the values in the list are at least x, without telling you what the first element is (it might be x, or it might be something bigger; we just don’t know yet).

Using this type, it is not hard to write infDiff and infIntersect in a way that is guaranteed not to go into infinite recursion, even when called on infinite lists, since every recursive call will be guarded by a constructor (a Cons constructor, in the case of finding a value which is actually contained in the output list, and an AtLeast constructor, in the case of finding one that isn’t). More importantly, this means that code calling infDiff and infIntersect doesn’t have to decide up front how far to look — it can decide on the fly, possibly making use of knowledge about the size of potential remaining list elements (i.e., it could keep running until being sure that any remaining elements are greater than 100), or data computed from the initial elements of the result list, and so on. I leave writing such implementations as an exercise. =)