Better support for existing records

[dgaw]

I understand this issue has been discussed briefly in #24 but I think it should be re-opened.

Enabling the preprocessor on a per-file basis requires a code reorganisation while adding manual instances of HasField is unnecessary boilerplate.

Is there a reason why we can't add a bit of syntax (say, a double curly bracket) that would ignore the setField substitution in certain record update expressions? E.g.

c {{ name = "Old " ++ name c }}

This way we could have the existing record behaviour when we need it (e.g. interfacing with records in 3rd party libraries) and the new dot-behaviour when we want it.

[ndmitchell]

Doesn't sound too unreasonable. Cc @DoctorRyner as I imagine such a thing would be useful to him.

I guess I'd like to understand why you are using this preprocessor. Is it just for the . syntax on new GHC versions? If so, we could switch to the real GHC instances, ditch a lot of complexity and avoid set field entirely. For syntax, one early version of the library made "x{}" a setField but left "x {}" alone - should that be reinstated?

[dgaw]

Thanks for the quick reply Neil!

I'm on GHC 8.2 and want to use your preprocessor as a better alternative to DuplicateRecordFields because DRF's lack of type inference is a bit annoying.

I'm not sure if I follow your suggestion about avoiding setField entirely. Wouldn't it make nested updates impossible even on newer GHC versions?

Re the syntax, I don't have a strong preference here, although the difference between "x{}" and "x {}" seems a bit too subtle and possibly error-prone.

[DoctorRyner]

Currently, I switched back to generic-lens + OverloadedLabels because of #24

I guess I'd like to understand why you are using this preprocessor

I use it to simplify my code, generic-lens are just way too verbose and use annoying "syntax" just to access fields that turn something simple like

test v1 v2 = v1.x + v2.z + v1.y * v2.y

into this mess

test v1 v2 = v1 ^. #x + v2 ^. #z + v1 ^. #y * v2 ^. #y

I find x{} | x {} confusing as well

Also, I use 8.6.5 and 8.4.4 most of the time

[ndmitchell]

I appreciate that x {} vs x{} is a bit annoying, but alas, it's the only thing that is consistent, works with both the preprocessor and the plugin etc. As a result, I've gone for that - you can always do x {- no -} {y=z} if you want to make it more explicit. Released as 0.2.2.

[DoctorRyner]

Thank you, I just noticed this change and I'm considering to switch back from generic-lens :)