deep record update

[Julian Bean]

This is (a) one of the big advantages of records and (b) why it's a mistake to have the record discussion without taking into account some notion of lens. Haskell field names are a red herring because they're selector functions - what we need is a record system which generates lenses and solves the namespacing issues.

Jules

On 19 Sep 2011, at 19:58, Edward Kmett wrote:

> If you use lenses you can do this today with no real need to adulterate the parser.
> 
> setL (l2 . l1) x rec
> 
> This goes one step further as it can be written point free so you don't even have to give rec a name if you don't want to. ;)
> 
> -Edward
> 
> On Mon, Sep 19, 2011 at 9:09 AM, Barney Hilken <b.hilken at ntlworld.com> wrote:
> All this talk about records got me thinking. I don't really like the current syntax for record update (because it looks too much like function application) but here is an extension to it which might be useful.
> 
> If you use nested records, many languages allow you to update the inner records directly, for example rect.bottomLeft.xCoord += 3. We could allow a similar thing in Haskell by extending the syntax like this:
> 
> fbind   ->      qvar = exp
>                |       qvar { fbind1 , ... , fbindn }
> 
> then
> 
>        rec { l1 { l2 = x }}
> 
> would mean
> 
>        rec { l1 = (l1 rec) { l2 = x }}
> 
> The advantage (apart from convenience) is that we don't have to repeat rec, which could be a complex expression.
> 
> Is this any use?
> 
> Barney.
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110920/55e32687/attachment.htm>