[Haskell-cafe] Re: Refactoring type-class madness
Andrew
andrew.webb at gmail.com
Sun Jul 18 17:55:01 EDT 2010
Hey hey,
Thanks for the response!
>
> 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:
>
Indeed, you seem to be correct. I was implementing concurrently in
haskell and in scala, and there seems to have been some leakage
between the two...
>
> 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.
>
Yes, I quite agree. I think I got into a "when all you have is a
hammer..." mindset. Thanks for the clarification.
> 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.
>
At first glance that does seem sensible, and was, in fact, my first
design; however, it doesn't pan out that way. The problem arises from
the fact that the two type of events have durations (so a start time,
and an end time) whereas the milestones are instantaneous events, and
which can occur with the span of an event. In different situations we
care about different relationships between events and milestones; so,
at times I care about whether an event is strictly before (i.e.,
starting and ending before) the milestone, but at other times I only
care about whether it starts before the milestone, and the situation
is the same for ending after, or occurring strictly after. Hence the
current design.
Thank you for taking the time to suggest it though!
Ta,
Andrew
More information about the Haskell-Cafe
mailing list