#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