[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

Gábor Lehel illissius at gmail.com
Fri Feb 10 11:46:08 CET 2012

On Fri, Feb 10, 2012 at 5:31 AM, Evan Laforge <qdunkan at gmail.com> wrote:
> 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

More information about the Haskell-Cafe mailing list