Records in Haskell

Matthew Farkas-Dyck strake888 at
Wed Jan 18 13:09:56 CET 2012

On 18/01/2012, Greg Weber <greg at> wrote:
> On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones
> <simonpj at>wrote:
>> But, the Has constraints MUST exist, in full glory, in the constraint
>> solver.  The only question is whether you can *abstract* over them.
>> Imagine having a Num class that you could not abstract over. So you
>> could write
>>   k1 x = x + x :: Float
>>   k2 x = x + x :: Integer
>>   k3 x = x + x :: Int
>> using the same '+' every time, which generates a Num constraint. The
>> type signature fixes the type to Float, Integer, Int respectively, and
>> tells you which '+' to use.  And that is exactly what ML does!
>> But Haskell doesn't.  The Coolest Thing about Haskell is that you get
>> to *abstract* over those Num constraints, so you can write
>>  k :: Num a => a -> a
>>  k x = x + x
>> and now it works over *any* Num type.
>> On reflection, it would be absurd not to do ths same thing for Has
>> constraints.  If we are forced to have Has constraints internally, it
>> woudl be criminal not to abstract over them.  And that is precisely
>> what SORF is.
> So I understand that internally a Has constraint is great for resolving the
> type.
> What is the use case for having the Has abstraction externally exposed?
> I think there is a great temptation for this because we would have a
> functionality we can point to that has some kind of extensible record
> capability.
> But I believe the Has abstraction to be a form of weak-typing more so than
> a form of extensibility. Just because 2 records have a field with the same
> name, even with the same type in no way signifies they are related. Instead
> we need a formal contract for such a relation. We already have that in type
> classes, and they can already be used for this very capability in a more
> type-safe way.
> My point is that Has abstractions are weak types and that likely we should
> be searching for something stronger or using type classes. If I am wrong
> then we should have convincing use cases outlined before we make this a
> goal of a records implementation, and still I don't see why it needs to be
> a blocking requirement if we are just trying to solve the basic records
> issue.
> Greg Weber

Has *is* a type class. It can be used and abused like any other.
Record members with the same key ought to have the same semantics; the
programmer must ensure this, not just call them all "x" or the like.

Weak types these are not. The selector type is well-defined. The value
type is well-defined. The record type is well-defined, but of course
we define a type-class to let it be polymorphic.

More information about the Glasgow-haskell-users mailing list