[Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update
qdunkan at gmail.com
Mon Feb 13 00:54:18 CET 2012
> 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
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.
More information about the Haskell-Cafe