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
Simon,
Yes, your summary is exactly what I meant.
2013/6/26 Simon Peyton-Jones simo...@microsoft.com:
In fact, your observation allows us to regard our proposal as consisting of
two entirely orthogonal parts
* Generalise the type of record field selectors
* Introduce period as reverse
On Thu, Jun 27, 2013 at 2:14 AM, AntC anthony_clay...@clear.net.nz wrote:
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
| Exactly! (I did tell you so:
|
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix
| billed as optional syntactic sugar)
I confess that I had not fully taken in this suggestion; thank you for
reminding me. The last round exceeded my input bandwidth,
On Thu, Jun 27, 2013 at 2:14 AM, AntC anthony_clay...@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).
Adam Gundry adam.gundry at strath.ac.uk writes:
I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla
n
Thank you Adam, (Simon)
I like the approach for Representation hiding. (That was something I was
particularly
... the orthogonality is also an important benefit.
It could allow people like Edward and others who dislike ...
to still use ...
Folks, I'm keenly aware that GSoC has a limited timespan; and that there
has already been much heat generated on the records debate.
Perhaps we could
On 6/27/13 8:37 AM, AntC wrote:
Folks, I'm keenly aware that GSoC has a limited timespan; and that there
has already been much heat generated on the records debate.
Perhaps we could concentrate on giving Adam a 'plan of attack', and help
resolving any difficulties he runs into. I suggest:
Adam
This (AntC's points 1-8) is the best plan yet. By getting rid of dot notation,
things
become more compatible with existing code. The only dodgy bit is import/export
in point 7:
7. Implement -XPolyRecordFields, not quite per Plan.
This generates a poly-record field selector function:
Somebody claiming to be Simon Peyton-Jones wrote:
It is kind of weird that
f . g means\x. f (g x)
but f.gmeansg f
Anything that makes f.g mean something different from f . g just makes the
code soup.
F . g being different from F.g is already *very* unfortunate. The
Somebody claiming to be Dominique Devriese wrote:
I would prefer to have dot notation for a
general, very tightly-binding reverse application, and the type of the record
selector for a field f changed to forall r t. r { f :: t } = r - t
instead of
SomeRecordType - t. Such a general reverse
Thanks everyone for the illuminating discussion, and for your awareness
of the dangers of bikeshedding. ;-) I think we are making progress though.
I like the idea of making -XFunnyDotSyntax or whatever a separate
extension. It's simple, resolves something of a love-hate issue, and
reduces
I'm reluctant to add yet another opinion, but, oh what the heck:
For me, lenses basically already solve the record problem. The only
missing thing is to integrate them better with record declaration
syntax. Having to rely on TH and then write a makeLenses splice is
just too much friction to
13 matches
Mail list logo
