Records in Haskell

[Barney Hilken]

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.


Here is a simple solution, using SORF:

The real problem is that the polymorphism of spam and offer is too general. We should each define new classes

>	class Has r "name" String => HasPersonalName r
>	class Has r "name" String => HasBrandName r

and make  each of our record types an instance of this class

>	instance HasPersonalName EmployeeRecord
>	instance HasPersonalName CustomerRecord
>	instance HasBrandName FoodRecord

then we can define functions with a more specific polymorphism

>	spam :: HasPersonalName r => r -> String
>	spam r = "Dear " ++ r.name ++ "\nHave you heard..."

>	offer :: HasBrandName r => r -> String
>	offer r = "Reduced! " ++ r.name ++ " 50% off!"

Now there is no danger of confusing the two uses of "name", because my records are not instances of HasPersonalName, they are instances of HasBrandName. You only use the class Has if you really want things to be polymorphic over all records, otherwise you use the more specific class.


This seems to me a much simpler approach than building the mechanism in to the language as DORF does, and it's also more general, because it isn't hard linked to the module system. Does it have any disadvantages?

Barney.