Hello, I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide. I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution. Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community. Let me know what you think! -Iavor
On Thu, Jan 29, 2015 at 12:15 AM, Iavor Diatchki
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
Immediate reaction: is there a conflict if the update-with-a-function syntax uses $= instead of :=? Idea being to imply that application is happening. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
1. I *love* the idea of not generating selector functions. It's worth implementing it as a separate extension regardless of this proposal's fate. 2. In H98, it is possible to do constructor-agnostic updates: data T = A { n :: Int } | B { n :: Int } f :: T -> T f x = x { n = 2 } It's not possible in your proposal. One could even argue that it was a bad idea in the first place, as it may lead to partiality. 3. Now that fields are not tied to selectors, do we need a separate mechanism/set of rules for exporting fields? Roman On 29/01/15 07:15, Iavor Diatchki wrote:
Hello,
I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide.
I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution.
Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community.
Let me know what you think!
-Iavor
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
It's not possible in your proposal. One could even argue that it was a bad idea in the first place, as it may lead to partiality.
On a second thought, isn't your update partial as well? In C { e | f1 = e1, f2 = e2 } what happens if e's constructor is not in fact C? This makes me somewhat uncomfortable. Roman On 29/01/15 10:14, Roman Cheplyaka wrote:
1. I *love* the idea of not generating selector functions. It's worth implementing it as a separate extension regardless of this proposal's fate.
2. In H98, it is possible to do constructor-agnostic updates:
data T = A { n :: Int } | B { n :: Int } f :: T -> T f x = x { n = 2 }
It's not possible in your proposal. One could even argue that it was a bad idea in the first place, as it may lead to partiality.
3. Now that fields are not tied to selectors, do we need a separate mechanism/set of rules for exporting fields?
Roman
On 29/01/15 07:15, Iavor Diatchki wrote:
Hello,
I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide.
I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution.
Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community.
Let me know what you think!
-Iavor
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hi, Am Mittwoch, den 28.01.2015, 21:15 -0800 schrieb Iavor Diatchki:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
Let me know what you think!
a small Optional Extension. If you allow Node { n | left = l, right = r} as an expression, then it would make sense to allow Node { n | left = l, right = r} as a pattern as well, meaning the same thing as n@Node {left = l, right = r} now. (Hardly important, but nice for consistency.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Thanks Iavor, It's been suggested before that the compiler should simply stop generating record selectors (see Trac #5972). I'm unconvinced that the benefit (being able to use the same name repeatedly) is worth the cost (being unable to use selector functions at all, without writing them out by hand or using TH). In particular, as an application programmer I would be dependent on what my libraries choose to do about records: they might not give me any selectors at all, they might give me lenses with the same names, etc. Given a piece of code that uses field names in expressions, I would no longer know what it means without finding out how it chooses to define fields. Consider, however, the current version of the redesigned ORF proposal: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesig... If you ignore all the stuff about the #x syntax (and hence are free to ignore all the types stuff), you end up with something extremely simple: * record field names can be reused * selectors and updates can be used only if unambiguous * construction and pattern-matching can be used freely An unambiguous update syntax could be useful, but that's mostly orthogonal to the ORF proposal (and an easy extension of it). I think this satisfies your goals 1 and 2. With the proposed design, however, we also gain: * the ability to use overloaded field names, either as selectors or as lenses, without using TH; * a syntax which generalises to other uses, completely separate from records (e.g. we can turn #x into a Symbol singleton); * interoperability with anonymous records proposals. Moreover, we have an implementation that shows the design works: the implementation needs some revision to use the #x syntax rather than renamer magic, and adapt to some finer points of the design, but the core ideas are all there. We've been putting this problem off for literally decades on the basis that more experimentation is needed. Now that we have a plausible-looking solution in the form of ORF, let's get it into GHC so people can try it. Adam On 29/01/15 05:15, Iavor Diatchki wrote:
Hello,
I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide.
I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution.
Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple
I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community.
Let me know what you think!
-Iavor
-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (5)
-
Adam Gundry -
Brandon Allbery -
Iavor Diatchki -
Joachim Breitner -
Roman Cheplyaka