On Tue, Oct 15, 2013 at 2:41 PM, AntC wrote:

- (What I was hoping for but didn't get.) No compiler flag to suppress creating selector functions. This would have allowed records to be declared re-using the same name; but left it entirely to the developer as to how to access them.

Does that mean that this won't work: module M where data T1 = C1 { f :: Int } data T2 = C2 { f :: Int } ? -- Johan

Johan Tibell writes: ...

Does that mean that this won't work: ...

Johan, a) try it b) read the wiki I pointed to (answer in the first few paras). c) go to the parent 'Records in Haskell' wiki page (which quotes a Yesod blog, with your example modulo alpha renaming). Adam's wiki points to "what I was hoping for" http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan#Hi dingrecordselectors I suggest you move this thread to cafe if it's going to go on in this vein.

Looping in Adam Gundry, who did the work! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of AntC | Sent: 15 October 2013 22:42 | To: ghc-devs@haskell.org | Subject: Re: Status update on overloaded records work? | | > Johan Tibell writes: | > | > I'm curious about the current status of the overloaded records work. | | Hi Johan, I think Adam has documented as he's gone along: | http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla | n | (And that points to implementation notes.) | | I'll leave Adam/Simon to comment more fully, but from my point of view | as | an observer with some 'skin in the game' ... | | > Is the design the same as when the project started? | | No: | - Higher-Ranked types can't be supported | -- and SPJ's initial proposal put a lot of weight on them. | There's an easy (IMO) work-round; | but it does compromise backward compatibility. | + Type changing update _is_ supported (with limits) | I think that was a justified trade-off for H-R types. | + Adam has been able to support Lenses. | | - (What I was hoping for but didn't get.) | No compiler flag to suppress creating selector functions. | This would have allowed records to be declared re-using the same | name; | but left it entirely to the developer as to how to access them. | (I was trying to promote the TH and/or Lenses cottage industries.) | | > Did we manage to keep the types simple? | | I guess simplicity is in the eye of the beholder ;-) | For 'gettable' fields, the sugar is as per SPJ's suggestion. | There isn't sugar for updating. | | The un-sugared types are pretty gnarly. | I suspect that'll mean obscure and confusing error messages. | | | AntC | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Simon Peyton-Jones writes:

| - (What I was hoping for but didn't get.) | No compiler flag to suppress creating selector functions. | This would have allowed records to be declared re-using the same | name; | but left it entirely to the developer as to how to access them. | (I was trying to promote the TH and/or Lenses cottage industries.)

This is an petty orthogonal design request, which is why it wasn't part of Adam's project.

The fishhooks are likely to be with naming and scoping (as you point out); and that was part of what Adam worked on.

However I could imagine some pretty puzzled users. ("I imported module M, which defines a type T with field f, but GHC says 'f is not in scope'". Turns out that M was compiled (via a command-line option) with -XNoRecordSelectors.)

The developer of module M is only going to switch on this option if they're wanting to re-use field names. So without the option, M wouldn't even compile. And they're going to provide some other way to access the fields. Very possibly a Lens. Very possibly a (overloaded) selector function f. Now perhaps there is some reason it won't work, or isn't ergonomic. But at the moment there's no way to even try. The Lens library has all sorts of TH work-rounds: * declare field labels with prefixes. * make sure the prefix is exactly the typename, with underscore. * strip those off with TH to create an overloaded selector function f.

I don't really buy it, but I don't massively object either, if someone wants to offer a patch.

Yes, that would be great! The write-up is at http://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields /NoMonoRecordFields AntC