Re: Records in Haskell

On 18/01/2012, Greg Weber wrote:

On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones 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.