On Fri, Feb 10, 2012 at 5:31 AM, Evan Laforge
You can also enforce invariants, etc. It would be a shame to have a nice record update syntax only to be discouraged from using it because it would tie you too tightly to the current shape of the data structure. There would always be a tension and every time I wrote down a new type I'd waste some time thinking: is the record big enough to want to define functions, or can I get away with direct access? Of course it may *get* bigger later so...
It's the same tension as direct access vs. accessors in the OO world, I guess.
I thought of this analogy also, but in the context of views/view patterns. They seem to fill a 2x2 grid (not going to try ascii art): accessor functions: map subcomponent of structure, read-only lenses: map subcomponent of structure, read-write view patterns: map whole structure, read-only views: map whole structure, read-write Any of these facilitate separation of interface and implementation: with functions and lenses you define a collection of them representing the logical subcomponents to serve as the interface, whereas with view patterns and views you define an entire new data structure to serve as the interface. (Views feel like they would be more powerful and flexible on this basis, but I haven't thought about it deeply. Perhaps at the price of being less efficient?) The subcomponent vs. whole structure disctinction might be a little bit superficial: there's nothing stopping you from defining a whole-structure lens. I think the difference between that and views is merely convenience of use, but I'm not completely sure. Unfortunately the page where I read a proposal about Views seems to have fallen off the internet and I only partly remember it, so I can't check if this is on the right track. I think it was the one linked from here: http://hackage.haskell.org/trac/haskell-prime/wiki/Views