I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones.
Indeed. I have my own version here:
http://code.haskell.org/yi/Yi/Accessor.hs
I'd rather use a standard package, but I could not contact the author of
Jean-Philippe Bernardy wrote: the
data-accessor package to join efforts.
I too have a home-rolled version nearly identical to this one. The only real difference is using a (whole -> part -> whole) modifier instead of ((part -> part) -> whole -> whole) in the dictionary type. That decision was salient for my particular uses, but on the whole I like the Yi.Accessor approach better. For an official API, I think a (setter = modifier . const) function would be helpful for brevity and clarity. The other difference, in terms of API, is I was using names "theX" and "resetX" rather than "getter" and "modifier" (I also have a "setX" which requires a class declaring an emptyX value for the whole type). I'm not too invested in my particular names, but I think having something short which isn't too evocative of the StateMonad is important. The reason I think it shouldn't be too evocative of State is that the functions are pure and keeping their names distinct gives a good mnemonic to remember which ones are State-ful and which ones are pure. Tim Newsham's approach with invertible functions is interesting, though it feels like it's another layer wrapped on top of the primitive idea of functional references. My code also had an extra layer lifting the explicit dictionaries into type class dictionaries. This was helpful for writing functions which are polymorphic over the state type, though it suffers from the limitation that you can only have a single accessor for each part type in a given whole type. -- Live well, ~wren