anation of the fundep/type-family/overlap
> issue here?
> Or is it explained on a wiki page?
>
Neither is it specifically about the Overloaded Record Fields design,
nor anonymous records -- it's just that you need a meaty application
like those to demonstrate the subtleties.
I've taken some time t
>
> The labelled "birthday = ..." approach seems
> tantalisingly close to data constructors:
>( Name "Fred", Birthday $ Date 28 4 2016 )
>
> Which takes us (perhaps) to HLIst-style
> Type-Indexed Products.
> How could they fit with ORF?
> Perhaps introduce an implicit label spelled same as the
> Adam Gundry well-typed.com> writes:
> ...
>
> P.S. If you have any thoughts on the interaction between ORF and
> encodings of anonymous records, I'd be interested to hear them.
Are you sure you want to open up that question? ;-)
Nikita's record library has certainly given food for thought.
| > I have been vacillating between type families and fundeps for the ORF
| > classes. I hadn't fully appreciated this point about overlap, but I
| > think it is a reason to prefer fundeps, which is the direction in
| > which I'm leaning. I'd be grateful for feedback on this issue though!
...
> > On 26/04/16 09:20, AntC wrote:
> > There's an intriguing comment here wrt anonymous records: ...
>
> I'm afraid the sentence on the wiki page is slightly misleading, ...
> with the change to functional dependencies,
> the overlapping instances solution works rather nicely,
> in that it
+1 for the -XDotPostfixApply proposal
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Overloaded-record-fields-tp5731998p5733121.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com
(sorry, accidentally failed to send this to the list)
All this extra syntax, whether it's ., #, or {} seems very heavy for a problem
described as very rare.
Why not simply use a declaration
field name
whose effect is to declare
name :: r {name ::t} = r - t
name =
Hi all,
I have amended the plan [1] as a result of the ongoing discussion,
including leaving the syntax alone for the time being, so record
projections are written prefix.
Regarding Barney's suggestion of field declarations:
On 01/07/13 10:50, Barney Hilken wrote:
All this extra syntax,
-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:
glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of AntC
| Sent: 27 June 2013 13:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
|
| ... the orthogonality is also an important
Malcolm Wallace malcolm.wallace at me.com writes:
I believe Simon's point is that, if dot is special, we can infer
the Has type above, even if the compiler is
not currently aware of any actual record types that contain a foo
field. ...
(For the record, I deeply dislike making dot
: 27 June 2013 13:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
|
| ... 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
Hi Evan,
1 - Add an option to add a 'deriving (Lens)' to record declarations.
That makes the record declare lenses instead of functions.
Well, no, that's exactly the kind of magic programming language hackery,
that Haskell shouldn't be part of.
Deriving should only add something, but not
Simon Peyton-Jones simonpj at microsoft.com writes:
I have, however, realised why I liked the dot idea. Consider
f r b = r.foo b
Thanks Simon, I'm a little puzzled what your worry is.
With dot-notation baked in (non-orthogonally), f would get the type
f :: (r {
On 28 Jun 2013, at 12:16, AntC wrote:
Thanks Simon, I'm a little puzzled what your worry is.
f r b = r.foo b
With dot-notation baked in (non-orthogonally), f would get the type
f :: (r { foo::Bool }) = r - Bool - Bool
With the orthogonal proposal, f is equivalent to
Malcolm Wallace malcolm.wallace at me.com writes:
With the orthogonal proposal, f is equivalent to
f r b = foo r b
I believe Simon's point is that, if dot is special, we can infer
the Has type above, even if the compiler is
not currently aware of any actual record types that
-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of AntC
| Sent: 27 June 2013 13:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
|
| ... the orthogonality is also an important benefit
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
backwards incompatibility for people who want overloaded record
fields in their existing code. Perhaps we can leave the arguments over
dot syntax for another thread?
There are a bunch of options for translating record fields into selector
functions:
* monomorphically, as in Haskell 98, which is simple
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
record fields extension for GHC as a
GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan
If you have any comments on the proposed changes
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Dominique Devriese
| Sent: 26 June 2013 13:16
| To: Adam Gundry
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
| I think it's a good idea to push forward on the records design because
| it seems futile
Of Dominique Devriese
| Sent: 26 June 2013 13:16
| To: Adam Gundry
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
| I think it's a good idea to push forward on the records design because
| it seems futile to hope for an ideal consensus proposal
Mateusz Kowalczyk fuuzetsu at fuuzetsu.co.uk writes:
On 24/06/13 11:04, Roman Cheplyaka wrote:
* Mateusz Kowalczyk fuuzetsu at fuuzetsu.co.uk [2013-06-24
10:47:09+0100]
Restricting function composition to have spaces around it will
require changing a large amount of existing code if
Simon Peyton-Jones simonpj at microsoft.com writes:
| record projections. I would prefer to have dot notation for a
| general, very tightly-binding reverse application, ...
| Such a general reverse application dot would
| allow things like string.toUpper and for me personally, it would
person.lastName.toUpper-- == toUpper (lastName person)
Oops! that should be one of:
person.lastName.head.toUpper
person.lastName.(map toUpper)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
| To: Adam Gundry
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
| I think it's a good idea to push forward on the records design because
| it seems futile to hope for an ideal consensus proposal.
|
| The only thing I dislike though is that dot
Hi everyone,
I am implementing an overloaded record fields extension for GHC as a
GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan
| I am implementing an overloaded record fields extension for GHC as a
| GSoC project. Thanks to all those who gave their feedback on the
| original proposal! I've started to document the plan on the GHC wiki:
|
| http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
| Plan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 08:44, Adam Gundry wrote:
Hi everyone,
I am implementing an overloaded record fields extension for GHC as
a GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-06-24 10:47:09+0100]
Restricting function composition to have spaces around it will require
changing a large amount of existing code if one is willing to use it.
I assume this semantics will be triggered only by an extension, so
there'd be no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 11:04, Roman Cheplyaka wrote:
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-06-24
10:47:09+0100]
Restricting function composition to have spaces around it will
require changing a large amount of existing code if one is
willing to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 11:05, Mateusz Kowalczyk wrote:
On 24/06/13 11:04, Roman Cheplyaka wrote:
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-06-24
10:47:09+0100]
Restricting function composition to have spaces around it will
require changing a large
On 06/24/2013 08:44 AM, Adam Gundry wrote:
Hi everyone,
I am implementing an overloaded record fields extension for GHC as a
GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac
wrote:
On 06/24/2013 08:44 AM, Adam Gundry wrote:
Hi everyone,
I am implementing an overloaded record fields extension for GHC as a
GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan on the GHC wiki:
http
44 matches
Mail list logo
