[GHC] #11805: Ability to use record fields for automatic derivation of user-defined classes.

[GHC]

#11805: Ability to use record fields for automatic derivation of user-defined
classes.
-------------------------------------+-------------------------------------
           Reporter:  Tientuine      |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  7.10.3
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 I propose that the compiler be empowered to automatically derive a user-
 defined class when a data type has fields that match (in both name and
 type) methods sufficient for a minimal complete definition of the class.
 (There is some overlap between this idea and the much larger and more
 contentious issue of extensible records generally.)

 I am relatively new to Haskell, but have quickly run into the problem of
 field namespacing. As a simple example, suppose we are creating a game
 with data types for Room and Item, and values of each of these types will
 have a short name and a long description (possibly among other fields not
 detailed here). Currently, we must name our fields differently, as in:

 {{{#!hs
 -- ugh! prefixing the field names is ugly and tedious
 data Room = Room { rname :: String, rdescribe :: String, item :: Maybe
 Item }
 data Item = Item { iname :: String, idescribe :: String, value :: Int }
 }}}

 Classes seem a natural solution to this problem, but then we must either
 have superfluous field names or drop the use of field names altogether:

 {{{#!hs
 -- extracting a common interface as a class makes sense
 type Desc d where
     name     :: d -> String
     describe :: d -> String

 -- but now we either keep the ugly prefixed fields or drop fields entirely
 data Room = Room String String (Maybe Item)
 data Item = Item String String Int

 -- furthermore, it is tedious to implement these trivial observers
 instance Desc Room where
     name     (Room n _ _) = n
     describe (Room _ d _) = d
 instance Desc Item where
     name     (Item n _ _) = n
     describe (Item _ d _) = d

 }}}

 My proposal is to allow the compiler to rely on fields in order to
 automatically derive a user-defined class. This solves a couple of
 problems in a way that (I hope) is not excessively complex to implement.
 Such a feature would allow us to write code like the following:

 {{{#!hs
 -- class as a common interface still feels natural
 type Desc d where
     name     :: d -> String
     describe :: d -> String

 -- now we get shared field names and let the compiler do some of the work
 data Room = Room { name :: String, describe :: String, item :: (Maybe
 Item) }
     deriving Desc

 data Item = Item { name :: String, describe :: String, value :: Int }
     deriving Desc
 }}}

 Obviously, there are a couple of restrictions here:

 * fields of the same name in different records must have the same type
 * fields of the same name in different records are still ambiguous (no
 different than the current situation) if we do //not// derive a class that
 declares those field names
 * this is //not// intended to be a general solution for either extensible
 records or deriving classes automatically, it is very limited in scope

 P.S. This is my first Ticket and attempt to get involved in the community,
 and I'm not yet sure of the correct tags to use. Please be gentle. :)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11805>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler