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 <[EMAIL PROTECTED]> 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 > > _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
