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 have
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 backward
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 revers
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
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:
>
>
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
>
> ... 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 c
> Adam Gundry 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 trying to
On Thu, Jun 27, 2013 at 2:14 AM, AntC 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-comp
| 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 wrote:
> > Edward Kmett 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
Simon,
Yes, your summary is exactly what I meant.
2013/6/26 Simon Peyton-Jones :
> 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 function applicatio
12 matches
Mail list logo
