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