Simon Peyton-Jones writes: | Funnily enough, I'm currently ruminating on the possibility of adding | extensible records to GHC. My current thought is: much like TRex, | except with 'has' predicates instead of 'lacks' predicates. That would | give | polymorphic field selection and update | but not polymorphic record extension : | Question: does anyone really care about polymorphic extension. Yes! But my reasons are of dubious merit, so I'd better come clean and state them. - When handling records which have come out of a database (or EDI file or suchlike), with the results needing to go into a database too, I find I tend to copy some fields directly into the result record, from fields of the same name in other records. (COBOL, anyone? move by name rec1 to rec2.) - Some time in the future (Haskell 2?), I'd like to see convergence between Haskell's module system and records. Records with polymorphic extension would be a step in that direction: they'd support reexporting as in: module A(f, g, module B) where import B ... Have you considered asymmetric merge, as an alternative to Trex-style extension? For example, this function f x = x { l <- (3::Int) } would have this type f :: (r has l::Int) => r -> r