Records in Haskell

[wren ng thornton]

On 2/25/12 10:18 AM, Gábor Lehel wrote:
> On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken<b.hilken at ntlworld.com>  wrote:
>> After more pondering, I finally think I understand what the DORFistas want. Here is an example:
>>
>> You want to define records which describe people, and include (among other things) a field called "name". There might be several different record types with a name field, depending on whether the record refers to a customer, an employee, a business contact etc., but in each case "name" is the name of the person to which the record refers. You then write various functions which assume this, such as
>>
>>>        spam :: Has r "name" String =>  r ->  String
>>>        spam r = "Dear " ++ r.name ++ "\nHave you heard..."
>>
>> Now I want to define records which describe products, and I also use a field "name" in the same way, except that it is the brand name of the product. I also define functions such as
>>
>>>        offer :: Has r "name" String =>  r ->  String
>>>        offer r = "Reduced! " ++ r.name ++ " 50% off!"
>>
>> It doesn't make any sense to apply your functions to my records or vice-versa, but because we both chose the same label, the compiler allows it. Putting the code in separate modules makes no difference, since labels are global.
>
> Exactly!

FWIW, this is the concern I alluded to earlier. Namely that we may want 
to have two (or more), er, 'classes' of records--- where a field is 
polymorphic over an individual class, but we don't want those classes to 
merge simply because they happened to choose the same name and type for 
the field.

I'm not sure it's a good proposal, but it seems like the only way to 
handle this issue is to (1) introduce a new kind for 
semantically-oriented field names, and (2) make the Has class use that 
kind rather than a type-level string. By (1), what I mean is that rather 
than referring to the field as "name", we would declare PersonalName and 
BrandName and then use those in lieu of the string. And if we do that, 
then (2) demands that we must somehow make explicit which one we mean, 
should we want the `name` field to be polymorphic for some given record 
declaration.

-- 
Live well,
~wren