Records in Haskell

[Matthew Farkas-Dyck]

On 18/01/2012, Greg Weber <greg at gregweber.info> wrote:
> On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones
> <simonpj at microsoft.com>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.