[Haskell-cafe] Refactoring type-class madness

[wren ng thornton]

Andrew Webb wrote:
> Because, at the basic level all of the experiments share this type of
> data, it seems that I should be able to write analysis functions that
> work for any experiment. However, the experiments differ in the
> stimuli used, and associated with each stimulus set is a set of
> "milestones" that give times at which important things happen in the
> stimuli, and "regions of interest" that give areas of the visual scene
> that are considered important. For a single experiment I would have:
> 
> data Experiment = Exp [Trial]
> data Trial = Trial [Event] (Map MileStone Time)
> data MileStone = M1 | M2 | ...
> 
> [...]
> 
> So, I was wondering whether there was something wrong with my basic
> model which leads to this ugly type class, or whether this is the
> proper way forward. Either is fine, really, it would just be nice to
> know for certain.

In sounds like you're trying to use typeclasses as if they were 
OO-classes, which is a good way to confuse yourself. What you probably 
want is just parametric polymorphism. For example, if every experiment 
is a sequence of trials, and every trial is a sequence of events with 
some milestones, then you can get the generality you want with:

     data Experiment m = Exp [Trial m]
     data Trial m = Trial [Event] (Map m Time)
     data Event = Fixation {...} | Saccade {...}

     data A = MS_A1 | MS_A2 | ... deriving (Ord, Enum)
     data B = MS_B1 | MS_B2 | ... deriving (Ord, Enum)
     ...

then you would pass around (Experiment A), (Experiment B), etc. The 
reason for the Ord instances is so you can use them as keys in Map, and 
the reason for Enum is just so you have a generic interface for listing 
all the milestones (though getting the keys of the map may suffice).

The main reason for wanting to use typeclasses is when you have a common 
interface (i.e. set of function names and types), but the 
implementations of that interface are structurally/algorithmically 
different. If the structure of the implementation is the same and only 
the type of some component changes, then parametric polymorphism is the 
way to go.


Off-topic to your original question, it seems like a better model for 
your data might be to treat milestones as a third kind of event. Thus, a 
trial is just a sequence of events, which could be subject events 
(fixation, saccades) or experimental events (milestones, etc). This is 
assuming that your processing only cares about how patient events occur 
relative to experimental events, and that you don't need access to 
experimental events separately.

If you need to be able to jump around to different events, then you 
could use Trial[Event](Map m [Event]) and construct the map after 
reading input by walking over the list of events and storing pointers to 
the subsequence beginning with each milestone:

     computeMilestones :: Trial m -> Trial m
     computeMilestones (Trial es m) = Trial es (go es m)
         where
         go []         m = m
         go es@(e:es') m = go es' (m' e)
             where
             m' (MS x) = insert x es m
             m' _      = m


-- 
Live well,
~wren