Opened 3 weeks ago

Last modified 3 weeks ago

#16232 new feature request

Add setField to HasField

Reported by: adamgundry Owned by: adamgundry
Priority: normal Milestone: 8.10.1
Component: Compiler (Type checker) Version: 8.7
Keywords: ORF, GHCProposal Cc: NeilMitchell, simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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

\ 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?

Change History (6)

comment:1 Changed 3 weeks ago by mpickering

It seems quite straightforward to generate the necessary core. I think you mean that you would generate:

\ r x -> case r of MkT _ bar -> MkT x bar

You don't need to mention any wired-in Ids or anything so it seems simple?

It also doesn't seem like a lot of work to me in the grand scheme of things so I wouldn't mind doing it every time one of these constraints is solved.

comment:2 Changed 3 weeks ago by simonpj

I suggest taking the direct path, and generate an update function for each field. Its more work than Matthew says because we may need to evaluate the argument (for strict constructors) or unbox it (if the argument is UNPACKed).

This would replace the selector function would it not? The new function is a selector and update function?

comment:3 Changed 3 weeks ago by adamgundry

Owner: set to adamgundry

I suggest taking the direct path, and generate an update function for each field.

Sorry, to be clear, do you mean the approach of generating renamed syntax at definition sites?

Its more work than Matthew says because we may need to evaluate the argument (for strict constructors) or unbox it (if the argument is UNPACKed).

Exactly, perhaps my example didn't do a good job of conveying the awkward points here. Let me see if I understand correctly what generating Core directly needs to do in the general case:

  • When we pattern match in Core, we match on the *worker* (binding its existential tyvars, theta and the arguments as given by dataConInstSig).
  • We can use dataConBoxer to build let-bindings for the arguments to the wrapper out of the bound variables from matching on the worker.
  • We need to construct an application of the *wrapper* to appropriate boxed arguments, replacing the one that corresponds to the field being updated with the new value. I don't understand very clearly how to do this. In particular, I'm not sure how to figure out the order in which to instantiate type variables and dictionaries in the wrapper's type.

comment:4 Changed 3 weeks ago by mpickering

You are right that does seem a bit tricky.

Another possibility is generating renamed syntax when solving the constraint then type checking it and desugaring it using tcExpr and dsExpr to generate the necessary evidence? This is all possible to do in ClsInst.

comment:5 Changed 3 weeks ago by simonpj

Sorry, to be clear, do you mean the approach of generating renamed syntax at definition sites?

Yes -- essentially replacing the stuff where we generate record selectors by stuff that generates this compound selector/updater function; plus perhaps generating the legacy selector function from that.

comment:6 Changed 3 weeks ago by RyanGlScott

Keywords: GHCProposal added
Note: See TracTickets for help on using tickets.