Question

What I am talking about is that it is not possible to define:

data A = A {name :: String}
data B = B {name :: String}

I know that the GHC just desugars this to plain functions and the idiomatic way to solve this would be:

data A = A {aName :: String}
data B = B {bName :: String}

class Name a where
  name :: a -> String

instance Name A where
  name = aName

instance Name B where
  name = bName

After having written this out I don’t like it that much … couldn’t this typeclassing be part of the desugaring process?

---

The thought came to me when I was writing some Aeson JSON parsing. Where it would have been too easy to just derive the FromJSON instances for every data type I had to write everything out by hand (currently >1k lines and counting).
Having names like name or simply value in a data record is not that uncommon.

http://www.haskell.org/haskellwiki/Performance/Overloading mentions that function overloading introduces some runtime overhead. But I actually don’t see why the compiler wouldn’t be able to resolve this at compile time and give them different names internally.

This SO question from 2012 more or less states historical reasons and points to a mail thread from 2006. Has anything changed recently?

Even if there would be some runtime overhead most people wouldn’t mind cause most code hardly is performance critical.

Is there some hidden language extension that actually allows this? Again I am not sure … but I think Idris actually does this?

Answer 1

Using the record syntax

data A { name :: String }

implicitly defines a function

name :: A -> String

If define both A and B with a { name :: String }, we have conflicting type definitions for name:

name :: A -> String
name :: B -> String

It’s not clear how your proposed implicit type classes would work because if we define two types

data A { name :: String }
data B { name :: Text }

then we have just shifted the problem to conflicting type class definitions:

class Has'name a where
     name :: a -> String

class Has'name a where
     name :: a -> Text

In principle this could be resolved one way or another, but this is just one of several tricky conflicting desirable properties for records. When Haskell was defined, it was decided that it was better to have simple if limited support rather than to try to design something more ambitious and complicated. Several improvements to records have been discussed at various times and there are perennial discussions, e.g. this Haskell Cafe thread. Perhaps something will be worked out for Haskell Prime.