Why doesn't GHC Haskell support overloaded record parameter names?

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.

Answer 2

Many, mostly minor reasons. One is the problem raised by a better answer, overloading just on the first argument is insufficient to handle all the useful cases.

You could "desugar"

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

into

class Has'name a b | a -> b where
    name :: a -> b

data A { aName :: String }
instance Has'name A String where
    name :: aName

data B { bName :: Text   }
instance Has'name B Text   where
    name :: bName

but that would require GHC extensions (Functional Dependencies) that haven't made it into the standard, yet. It would preclude using just 'name' for record creation, updates, and pattern matching (view patterns might help there), since 'name' isn't "just" a function in those cases. You can probably pull off something very similar with template Haskell.

Answer 3

The best way I found, is to use a preprocessor to solve this definitely rather stupid problem.

Haskell and GHC make this easy, because the whole Haskell parser is available as a normal library. You could just parse all the files, do that renaming scheme (e.g. « data A { name :: String } » and « let a = A "Betty" in name a » into « data A { a_Name :: String } » and « let a = A "Betty" in aName a ») depending on the type of data the name function is applied to, using the type resolver, and write them out for compilation.

But honestly, that should be integrated into GHC. You’re right: It’s silly that this isn’t included.