> 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe