A Haskell implementation of skeletal set - a set equipped with an equivalence relation. SkeletalSet is a useful data structure when equivalence is chosen not to be equality. This allows to influence the membership of the elements in a set.

Here we have chosen to use a specific variant of equivalence of transforming the elements to comparable intermediaries. Although it does not make every equivalence relation possible, it is a practical choice for a lot of computations.

Usage

When manipulating collections of objects in the real world, we often use lists/arrays. Sometimes we need to represent some properties of the relation between the elements though, and the lists do not provide such possibility. This library not only provides the guarantee that a skeletal set is correct by construction, but also that the manipulations will not change its structure.

We use it to run computations over time series of sampling data, collections of users (who are unique by username or email) - to keep the same structure as the one which would be used in the database with unique indexes.

To implement equivalence we chose to use a data class EquivalenceBy which provides a method of mapping an element to an intermediary, which is then used for comparison and ultimately lead to a choice of the members.

The type is `SkeletalSet e a` where a is the member type and e is the type of equivalence intermediary. To chose the members of the skeletal set we compare the e(quivalences) of the elements with each other.

The definition of `EquivalenceBy e a` is

class EquivalenceBy e a where
  eqRel :: a -> e

To give a simple example of how the library could be used we will combine apples and oranges to a SkeletalSet of fruit names by colour. We want one fruit per colour as a result and don't care if its apple or an orange.

import Data.SkeletalSet (SkeletalSet)
import qualified Data.SkeletalSet as SkeletalSet

data Colour = Red | Green | Blue deriving (Eq,Ord)

instance EquivalenceBy Colour (Colour,String) where
  eqRel = fst

apples, organges, fruits :: SkeletalSet Int (Int,String)
apples  = SkeletalSet.fromList [(Green,"golden delicious"), (Orange,"honeycrunch")]
oranges = SkeletalSet.fromList [(Orange,"seville"), (Red,"blood orange")]

fruits = apples union oranges
-- > [(Green,"golden delicious"), (Orange,"seville"), (Red,"blood orange")]

One can see the benefit of using a SkeletalSet instead of Data.List because with the latter, we would have to use nubBy every time the data is transformed.

When performing a union, our implementation would use max between two equivalent elements to resolve the conflict. Bear in mind, that the elements, though equivalent, might not be equal. In the example above, ordering of "seville" is bigger than "golden delicious" thus (Orange, "seville") is chosen in the result.

Friends of friends and computation on union

For another example, lets get all the users of two different services F and G. We are not interested in the different details, but want the instance of the users to be unique.

type Email = String
data User = User {
  email :: Email,
  contacts :: Int
  } deriving (Eq,Show)

instance EquivalenceBy Email User where
eqRel u = email u

usersF, usersG, allUsers :: SkeletalSet Email User
usersF <- getUsers F
usersG <- getUsers G

allUsers = SkeletalSet.unionWith mergeContactDetails usersF usersG

mergeContactDetails :: User -> User -> User
mergeContactDetails a b = User (email a) (contacts a + contacts b)
-- ... --

We assume that here are equivalent elements in both sets - in this case they have the same email address. Thus we use unionWith to merge the other details of the contact. Here, we could also do computations and, for example, sum the number of friends/contacts from both services.

Here is also one of the shortcomings of the library. mergeContactDetails choses the email of the first argument. Since in the context of unionWith, the emails of the first and the second users are the same. It is not nice from the perspective of the function itself though.

SkeletalSet.size allUsers Would give us the amount of all unique users in both services together.

Future Work

• There is an unproven hypothesis about a relation between skeletal sets and Quotient Sets. It seems, that a `SkeletalSet (a,b) (a,b,c)` is equivalent to a `QuotientSet a (SkeletalSet b (a,b,c))`. This means that every QuotientSet can actually be represented as a skeletal set.
• Performance is another issue. Current implementation uses the `newtype SkeletalSet x y = SkeletalSet (Map x y)` which may be inefficient.