|  "wired" into record selectors, which can't be undone later. I think we
|  can fix some of that by desugaring record definitions to:
|  
|  data T = MkT {x :: Int}
|  
|  instance FieldSelector "T" T Int where
|       fieldSelector (MkT x) = x
|  
|  Then someone can, in a library, define:
|  
|  instance FieldSelector x r a => IV x (r -> a) where
|       iv = fieldSelector
|  
|  Now that records don't mention IV, we are free to provide lots of
|  different instances, each capturing some properties of each field,
|  without committing to any one style of lens at this point. Therefore,
|  we could have record desugaring also produce:
|  
|  instance FieldSetter "T" T Int where
|      fieldSet v (T _) = T v
|  
|  And also:
|  
|  instance FieldSTAB "T" T Int where
|      fieldSTAB = ... the stab lens ...

OK, I buy this.  

We generate FieldSelector instances where possible, and FieldSetter instances 
where possible (fewer cases).

Fine.



Cutting to the chase, if we are beginning to converge, could someone (Adam, 
Neil?) modify the Redesign page 
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign 
to focus on plan B only; and add this FieldGetter/Setter stuff?

It's confusing when we have too many things in play.  I'm sick at the moment, 
so I'm going home to bed -- hence handing off in a hopeful way to you two.

I have added Edwards "import Field(x)" suggestion under syntax, although I 
don't really like it.

One last thing: Edward, could you live with lenses coming from #x being of a 
newtype (Lens a b), or stab variant, rather than actually being a higher rank 
function etc?  Of course lens composition would no longer be function 
composition, but that might not be so terrible; ".." perhaps.  It would make 
error messages vastly more perspicuous. And, much as I love lenses, I think 
it's a mistake not to abstraction; it dramatically limits your future wiggle 
room.



I really think we are finally converging.

Simon
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to