OK, we could implement lenses, make `tempo' a lens instead of a selector, desugar the update syntax to call the update 'method' out of the lens, ... And of course somehow arrange the sugar that when `tempo' appears in other contexts we take the select 'method'.
implement lenses - Done, of course. make 'tempo' a lens instead of a selector - Done, but with TH. desugar the update syntax - Not necessary, and normal function syntax is more flexible than special update syntax. arrange for 'tempo' in other contexts to be the select method - If I'm understanding correctly, then this is also not necessary. If we are using normal function syntax then there are no "other contexts".
You write up the proposal, and think through all the changes it would involve over Haskell/GHC as is, and then we can compare it to all those other proposals.
So no proposal is necessary, because it's already implemented. However:
Now in return for me answering that, please answer the questions in my earlier post about what limitations on update you'd like: * record-type changing? * Higher-ranked fields? * How many forall'd variables? * Constrained forall'd variables?
If record update is a normal function then all of these questions are moot. However, if it uses lenses then, focusing on type changing first, you raise a good point. All the lens libraries I know of have a 'set' function like 'Lens a b -> b -> a -> a', and so can't change the type of the record the way record update syntax can. That's a serious weakness, and you're right that a real proposal shouldn't go forward without a solution for it. I don't understand enough about the issue yet to know from where exactly this weakness arises, and what would be needed to solve it in the context of lenses, e.g. in a data structure that can be passed to a normal function rather than as special syntax. If I understood it better then perhaps I could suggest something to address exactly that weakness in an orthogonal way. I'll have to think about it more.