[Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update

Evan Laforge 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
> 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.



More information about the Haskell-Cafe mailing list