Records in Haskell

Ian Lynagh igloo at earth.li
Thu Mar 1 22:14:55 CET 2012


On Thu, Mar 01, 2012 at 08:52:29PM +0000, AntC wrote:
> Ian Lynagh <igloo <at> earth.li> writes:
> 
> > 
> > On Thu, Mar 01, 2012 at 07:58:42AM +0000, AntC wrote:
> > > 
> > > SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them 
> because 
> > > they're new-fangled, I'm opposed because I can't control the namespace.)
> > 
> > I haven't followed everything, so please forgive me if this is a stupid
> > question, but if you implement this variant of SORF:
> > 
> >     
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Scopeco
> ntrolbygeneralisingtheStringtypeinHas
> > 
> > then do you get the behaviour of SORF when using field names starting
> > with a lower-case letter, and DORF when they start with an upper-case
> > letter?
> 
> And you get "In my opinion, this is ugly, since the selector can be either a 
> type name or a label and the semantics are nonsame. Rather, we need scoped 
> instances." [SPJ]

That comment was from strake888, not SPJ?

Personally, in the context of Haskell (where the case of the first
character often determines the behaviour, e.g. a pattern of Foo vs foo),
I don't think it's too bad.

> So if we open the gate for "ugly", do we also open it for "hacks" and 
> for "unscalable"?
> 
> Then we also have a solution for updating higher-ranked typed fields.
> 
> I guess this is all for decision by the implementors.
> 
> If we need to go into scoped instances, I'd be really scared -- that seems 
> like a huge, far-reaching change, with all sorts of opportunity for mysterious 
> compile fails and inexplicable behaviour-changing from imports.
> 
> I have some creative ideas for introducing overlapping instances; shall I run 
> them up the flagpole as well?

I'm getting lost again.

But I think you are agreeing that (leaving aside the issue of whether
the design is reasonable) the above variant would indeed allow the user
to choose the behaviour of either SORF or DORF.


Thanks
Ian




More information about the Glasgow-haskell-users mailing list