Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

2010-02-27 Thread Jon Fairbairn
Evan Laforge writes: > That's a good point, but even if not totally logical I think the > automatic "Rec -> X" function is more important than the X meaning. [...] > It might be nice to do the same with update functions, but those > aren't even generated automatically (anyone got a generics thin

Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

2010-02-27 Thread Jon Fairbairn
Anthony Clayden writes: > (I know how you're always looking for things to take out of > Haskell ...) > > I can see the ugliness of having a name with two > incompatible types (especially in the same scope). Granted. > After all, the program text declares { f :: Int }, and in > all uses of the fi

Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

2010-02-25 Thread Evan Laforge
> (I know how you're always looking for things to take out of > Haskell ...) > > I can see the ugliness of having a name with two > incompatible types (especially in the same scope). That's a good point, but even if not totally logical I think the automatic "Rec -> X" function is more important th

PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

2010-02-25 Thread Anthony Clayden
>Isaac Dupree writes: > On 02/24/10 13:40, Martijn van Steenbergen wrote: > > Ian Lynagh wrote: > >> I have a feeling I'm in the minority, but I find record punning an ugly > >> feature. > >> > >> Given > >> data T = C { f :: Int } > >> we implicitly get > >> f :: T -> Int > >> which punning shado