Records (was Re: [Haskell] Improvements to GHC)
rob.ennals at gmail.com
Tue Nov 22 09:32:47 EST 2005
Since discussion has returned to records, it might be useful for me to
post a link to a proposal that I knocked up a while back when this
topic came up a few years ago:
The basic idea is to keep records largely as they are, but add two extensions:
- field getter functions are placed in type classes
- fields desugar to setter functions as well as getters
Useful features of this approach are:
- backward compatibility with existing code
- the existing type-class mechanism is used for shared field names
- setters can be redefined if a type is changed, just as getters can now
To go through Dave's issues:
1. Field namespaces: solved by using type classes
2. Multi-constructor getters: solved by desugaring to functions
3. "Safe" getters for multi-constructor data types: ditto
4. Getters for multiple data types with a common field: solved by
type-classes (no special "constains" feature required)
5. Setters as functions: yep
6. Anonymous records: not supported
7. Unordered records: yep (if I understand the problem correctly)
And Georg's points:
8. Subtyping: yep -using type classes
9. higher order versions for selecting, updateing ... : not sure what
is meant here
Of course, my proposal might very well not do what you want, but I
thought it was worth posting it again.
Hope people find this useful.
On 11/22/05, Johannes Waldmann <waldmann at imn.htwk-leipzig.de> wrote:
> On records in Haskell - can we start by formulating requirements
> (design goals). What do we want from a record system,
> and what are non-goals.
> Some of the proposals here sound like records should be more like
> objects (with some kind of inheritance). Do we really want this?
> We already have inheritance (for interfaces). Isn't that enough?
> My main objection is that concrete data types (e. g. records)
> should not be exposed by a module anyway,
> and should definitely not be a base for derivations
> (Compare the OO design pattern literature).
> Still if they are exposed (or while we're inside a module),
> what makes the current records quite impractical
> is the namespace issue (for component names).
> Sure, one thing would be to invent some ad-hoc solution
> (automatic qualification by type name or something)
> but another possibility is to allow ad-hoc polymorphisms
> generally in the language.
> Just my 2 cent (and none of them new, I'm afraid)
> -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
> ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
> Haskell mailing list
> Haskell at haskell.org
More information about the Haskell