| From: Ross Paterson [mailto:[EMAIL PROTECTED] | | On Thu, Mar 04, 2004 at 09:21:23AM -0000, Simon Peyton-Jones wrote: | > My personal view is this: we should have adopted the ML view of records. | > It solves the immediate problem, and no more elaborate scheme seems | > sufficiently "right" to be declared the winner. Alas, like all other | > proposals, it's not backward compatible, and hence not likely to fly. | | About a year ago, you were toying with a simple polymorphic system with | just "has" predicates. If these were automatically derived, it seems | you'd get something quite close to backward compatible, except for the | pesky extra lifting in record types, and not being able to omit fields | when constructing the record. (And update might not statically check | that all fields belong to the same constructor, for the simple version | of the type system.) Is that just too clunky?
It's possible, but I don't know. Speaking for myself, I've rather lost motivation on the records front, because the design space does not seem to have a clear optimum point. Adding has predicates in full glory seems overkill to get re-use of labels. Ah, but they also give you polymorphic record operations! Yes, but so do other versions, with different and rather subtle technical tradeoffs. That's why I've backed up to something extremely simple: either (a) disambiguate record labels by qualifying with the type constructor or (b) go the ML route. None of this is to discourage people from experimenting with variants -- quite the reverse. That's how we may find out what a good system is. Simon _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell