Overloaded record fields

Brandon Allbery allbery.b at gmail.com
Thu Jun 27 12:54:48 CEST 2013

On Thu, Jun 27, 2013 at 2:14 AM, AntC <anthony_clayden at clear.net.nz> wrote:

> Does the lens approach meet SPJ's criteria of:
>  * It is the smallest increment I can come up with that
>    meaningfully addresses the #1 pain point (the inability to
>    re-use the same field name in different records).
>  * It is backward-compatible.

It's difficult to get more backward compatible than "is already working,
without any changes to the compiler or standard libraries at all". Note in
particular that (.) is not redefined or changed. I think the only pain
point is code that itself defines (^.) or functions beginning with an

As for reusing the same field in different records, the point of lens is
it's a generic accessor/mutator mechanism. It doesn't just support
different records, it supports different pretty much everything — no
significant difference between a record, a tuple, a list, a Map, .... And
it composes very well, so it's absurdly easy to drill down into a complex
nested structure.

brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130627/4775db3d/attachment.htm>

More information about the Glasgow-haskell-users mailing list