Records (was Re: [Haskell] Improvements to GHC)

[Rob Ennals]

Hi guys,

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:

http://www.cambridge.intel-research.net/~rennals/records.pdf

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.


-Rob


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
> http://www.haskell.org/mailman/listinfo/haskell
>
>