Overloaded record fields
anthony_clayden at clear.net.nz
Thu Jun 27 08:14:01 CEST 2013
> Edward Kmett <ekmett <at> gmail.com> writes:
> Let me take a couple of minutes to summarize how the lens approach
tackles the composition problem today without requiring confusing changes
in the lexical structure of the language.
Thank you Edward, I do find the lens approach absolutely formidable. And I
have tried to read the (plentiful) documentation. But I haven't seen a
really, really simple example that shows the correspondence with H98
records and fields -- as simple as Adam's example in the wiki. (And this
message from you doesn't achieve that either. Sorry, but tl;dr, and there
isn't even a record decl in it.)
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.
[I note BTW that as the "Plan" currently stands, the '.field' postfix
pseudo-operator doesn't rate too high on backward-compatible.]
I do think that freeing up the name space by not auto-generating a record-
type-bound field selector will help some of the naming work-rounds in the
> template-haskell functions for lens try to tackle the SORF/DORF-like
aspects. These are what Greg Weber was referring to in that earlier email.
errm I didn't see an email from Greg(?)
More information about the Glasgow-haskell-users