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