I haven't got very far yet, but I feel like I'm already overcomplicating things, especially the module structure. The reason it has so many modules, even though there is hardly any code, is partly because I wanted to expose the properties of the MtGoxTicker record as lenses, without polluting the namespace with the underlying _accessors. Is this good or is there a more usual way of dealing with the problem?

The other problem I'm facing is with name collisions for record accessors. There are two versions of MtGoxTicker from different services - one with a subset of the properties, which is supposed to be faster (it isn't, but that isn't the point). The data types are here https://github.com/peterjoel/auto-trader/blob/6974d66ae51459479c19be291d075bbdeb718b53/AutoTrader/MtGox/Types.hs. One is commented one out while I decide what to do. What is the best way to model those records to avoid collisions, while not being confusing to users of the library? I am very tempted to use type classes, but that feels naughty. Using unique prefixes seems bad too - it would be nice for some code to be able to use them interchangeably if they don't need all the fields.

Is it possible to use unique names for the actual record accessors, but share the names of their lenses?

Thanks,

Peter