#16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: ORF | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the implementation of https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0042-record-set-field.rst I've made a start on the implementation but have a question on which I'd appreciate some input: how should the dictionary for `HasField` be generated? To recap, recall that at present, `HasField x r a` is coercible to `r -> a` so the dictionary can be constructed merely by taking the selector function for the field and wrapping it in an appropriate coercion. With the proposal, `HasField x r a` will instead be represented as `r -> (a -> r, a)` where the first component of the tuple is an update function. The problem is how to define this update function in Core. This function should perform case analysis on the record data type, where each case replaces the value of the field being updated and preserves all the other fields. For example, given a data type `data T = MkT { foo :: Int, bar :: Bool }` we need to generate {{{#!hs \ r x -> case r of MkT {foo = _, bar = bar} -> MkT { foo = x, bar = bar } }}} The most obvious approach is to generate well-typed Core for the update function directly, but this seems to be rather complex, in particular because of the worker/wrapper distinction, as one ends up reconstructing much of the typechecking/desugaring for record pattern matching and construction. This also seems like a lot of work to do every time a `HasField` constraint is solved. Would it be reasonable to generate update functions for fields at definition sites, as we do for selector functions? I've implemented this in the past, and it is relatively simple to generate renamed syntax to feed in to the type-checker. However, this would add some overhead for every field, even if `HasField` was not subsequently used, and would require some naming scheme for update functions. Or are there other options? Is there some way to solve a `HasField` constraint and construct its dictionary by emitting renamed syntax for subsequent type-checking, such that subsequently solving similar constraints will use the same dictionary? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16232 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler