5

How would you go about generating lenses with the new DuplicateRecordFields enabled?

I've already tried using makeLenses, but nothing was generated at all.

I also tried importing my constructors with a qualifier to prevent name clashes between fields and lenses, but that didn't help either.

Are there some unresolved issues with template-haskell as it pertains to this new extension (I found a ticket in the GHC bug tracker to that effect, but it's been closed), or am I missing something obvious?

SwiftsNamesake
  • 1,540
  • 2
  • 11
  • 25
  • IMHO, this extension is just vile. It's merely another ad-hoc measure to surpress the symptoms of the old Haskell records' design problem, but without actually fixing that problem in an idiomatic way. It's certainly not sensible to use this extension if you otherwise take a more modern course with lenses. A _proper_ way to get overloaded record fields [has been pointed out by Nikita Volkov](https://nikita-volkov.github.io/record/) – based from the ground up on first-class concepts and all lenses. – leftaroundabout Oct 03 '16 at 14:49
  • Do you know about the suite of record-related extensions outlined [here](https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields)? – SwiftsNamesake Oct 03 '16 at 15:00
  • Yes, and I've used these in the past, but ultimately they're unsatisfying. Lenses give you much more flexiblity; if you use lenses you just don't need any of these extensions. – leftaroundabout Oct 03 '16 at 15:15
  • I just wanted to get rid of the ugly mangled field names, that's all. – SwiftsNamesake Oct 03 '16 at 15:16
  • Also, according to one lens-maintainer, it should be possibly to use this new extension together with the TH functions (cf. [this issue](https://github.com/ekmett/lens/issues/680)) – SwiftsNamesake Oct 03 '16 at 15:18
  • Well – it is a bit annoying that the record fields themselves are essentially degraded to boilerplate when using `lens`. But I have begun to actually consider `_longUglyName` as a kind of “attention, unstable implementation detail” marker. It's somewhat handy – you can export everything, but automatically encourage to use the short, stable lens names instead of the implementation-specific record fields. – leftaroundabout Oct 03 '16 at 15:30
  • 1
    It turns out you can use a short arbitrary prefix, together with DuplicateRecordFields, to get overloaded lenses without using clunky names for the record fields. – SwiftsNamesake Oct 04 '16 at 02:03
  • Short arbitrary prefix is not the default rule after lens-4.6. You need to prefix whole type name with first character lowercased, or to use `makeLensesWith abbreviatedFields` – SeongChan Lee Mar 02 '17 at 01:31
  • Yes, I'm aware of that. I ended up using `abbreviatedFields`. – SwiftsNamesake Mar 02 '17 at 19:57
  • 1
    @SwiftsNamesake If you've solved your problem, why not post your solution and accept it as an answer so everybody else who come across this question would also know how to solve it? – Gal Dec 21 '18 at 14:24

1 Answers1

0

As a commenter pointed out, you can solve this with makeLensesWith, which is what I ended up doing:

makeLensesWith abbreviatedFields
SwiftsNamesake
  • 1,540
  • 2
  • 11
  • 25