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?

Aside: Could someone add a Idris tag to SO and this question? Maybe some one from that community could elaborate too. — fho, Jan 20 '13 at 06:11
Congrats on being the first question taged idris. If you want to read more about the subject there is a page on the [ghc wiki](http://hackage.haskell.org/trac/ghc/wiki/Records) and the [conversation on reddit](http://www.reddit.com/r/haskell/comments/kgd4g/the_records_problem_in_haskell_help_build_a/). — Davorak, Jan 20 '13 at 06:33
Thanks for the links. GHC docs doesn't seem to have a good ranking in my google results. — fho, Jan 20 '13 at 06:51
Note that for your specific Aeson problem, you could use [`Data.Aeson.TH`](http://hackage.haskell.org/packages/archive/aeson/0.6.1.0/doc/html/Data-Aeson-TH.html) to generate the instances automatically. It lets you normalize the keys e.g. to strip a type prefix from a record field name. — shang, Jan 20 '13 at 08:14
@shang Thanks for the advice. Sadly the TH parsers don't handle optional fields and my TH-fu isn't good enough to change that. — fho, Jan 20 '13 at 15:26

score 4 · Answer 1 · edited May 23 '17 at 10:30

4

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.

edited May 23 '17 at 10:30

Community

1
1

answered Jan 31 '13 at 15:12

Boyd Stephen Smith Jr.

3,182
14
39

This doesn't address polymorphic update or do the other typeclasses on the page – Jonathan Fischoff Jul 06 '13 at 20:09
If you need to do polymorphic update, you should probably have "name" still be defined inside a typeclass but make sure it has type Functor f => (a -> f b) -> s -> f t (or something "close") so that it can be used as a lens. At that point though, I'd generally err on the side having different, if long, names of the different lenses, via qualified imports. – Boyd Stephen Smith Jr. Jul 08 '13 at 18:57

score 3 · Accepted Answer · answered Jan 25 '13 at 23:27

3

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.

answered Jan 25 '13 at 23:27

daf

5,085
4
31
34

NO! We already knew that. And rejected it! That kind of brain-dead “thinking” is *exactly* the problem. What he meant was to have separate name spaces per data type! Just like with OOP, where A.name does not conflict with B.name. (name A) and (name B) shouldn’t either, for the exact same reason. I mean it could just internally desugar « 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 ». What’s the hold-up? – Evi1M4chine May 03 '13 at 15:03
4

@Evi1M4chine: Perhaps you should read some of the copious existing discussions on the issue before proposing something that doesn't actually work very well and then demanding that other people implement it. – C. A. McCann May 03 '13 at 17:00
@Evi1M4chine Then what is the type of `name` in your example? It needs to have some sort of principal type, otherwise type inference in general is going to break horribly. Now if you don't care too much about backwards type inference you could desugar into open non-injective type families. – semicolon Nov 15 '16 at 21:45

score 0 · Answer 3 · answered May 03 '13 at 15:09

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.

But not all types are known at compile time, so you have to worry about things such as principal types. What is the type of `name` in your example? It has to have ONE type for it to work well with the rest of Haskell in terms of type inference and such. If `A` and `B` are both an instance of `Monoid` for example, what does `name mempty` give you? — semicolon, Nov 15 '16 at 21:48

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

3 Answers3