Find disjoint integer intervals
The compactness and efficiency of the code is quite impressive.  The downside is that it's rather convoluted and difficult to understand.

Types

Annotations

Haskell types are very helpful, both when writing and reading code.  Type declarations should not be limited to top-level functions.  They can, and should, be added to local variables as well.  Even though it's not very complicated, the purpose of endpoints becomes much clearer when its type is explicitly stated:

endpoints :: [(a, b)] -&gt; [Either a b]
endpoints = foldr (\(a, b) m -&gt; (Left a):(Right b):m) []


It converts tuples into eithers.  It's obvious from the type that it works almost like a map, which we can make more explicit by using concatMap:

endpoints = concatMap (\(a,b) -&gt; [Left a, Right b])


Defining types

Another way in which types improve readability is that they hint at the semantics of a value.  Either is a very generic type, defining a newtype for interval endpoints might make things easier to understand.

Code organization

Related code should usually be grouped together.  The order, in which the local functions are defined, seems rather random.  Reorganizing those functions could benefit readability.

Variable naming

The variables (x:xs) a are shadowed in some functions.  That's confusing and will cause compiler warnings when compiled with -Wall.  I'd suggest renaming the outer (x:xs) to (y:ys).

This is just personal taste, but I'd also rename eitherValue to fromEither (in analogy to fromMaybe and fromJust).  This would make even more sense if a custom type was used (e.g. fromBorder).

Opinionated cleanup

Below is what I perceive as a cleaner version of this function.  It doesn't have the nice compactness of the original code, but uses the same basic algorithm.  The local functions are quite general and can easily be promoted to top level functions.  Reusable code is usually to be preferred.

import Data.Function (on)
import Data.List (group, sortBy)
type Border a = Either a a

disjoint' :: (Ord a) =&gt; [(a, a)] -&gt; [(a, a)]
disjoint' = concatMap consecutiveBordersToIntervals
            . groupBalancedBorders
            . sortBy (compare `on` fromBorder)
            . intervalBorders
    where
      intervalBorders :: [(a, a)] -&gt; [Border a]
      intervalBorders = concatMap $ \(x, y) -&gt; [Left x, Right y]

      groupBalancedBorders :: [Border a] -&gt; [[Border a]]
      groupBalancedBorders [] = []
      groupBalancedBorders xs = let (ys, zs) = spanBalancedBorders 0 xs
                                in ys : groupBalancedBorders zs

      spanBalancedBorders :: Int -&gt; [Border a] -&gt; ([Border a], [Border a])
      spanBalancedBorders _       []     = ([], [])
      spanBalancedBorders balance (x:xs) =
          let balance' = either (const $ balance + 1) (const $ balance - 1) x
          in case balance' of
               0 -&gt; ([x],xs)
               _ -&gt; let (ys,zs) = spanBalancedBorders balance' xs in (x:ys,zs)

      consecutiveBordersToIntervals :: (Eq a) =&gt; [Border a] -&gt; [(a, a)]
      consecutiveBordersToIntervals =
          (\xs -&gt; zip xs (tail xs)) . dedupSortedList . map fromBorder

      dedupSortedList :: (Eq a) =&gt; [a] -&gt; [a]
      dedupSortedList = map head . group

      fromBorder :: Border a -&gt; a
      fromBorder = either id id


This is as fast as the original, but arguably easier to read.  It also fixes a bug which caused empty intervals to be included.

&gt;&gt;&gt; disjoint [(1,5), (5,10), (1,10)]
[(1,5),(5,5),(5,10)]
&gt;&gt;&gt; disjoint' [(1,5), (5,10), (1,10)]
[(1,5),(5,10)]


As a final note, one should be aware that the algorithm makes some implicit assumptions on the topology of the intervals in a.  It would break down when intervals were allowed to have start points which are greater than their endpoint (think modular arithmetic).