interesting. it always seems that I get more responses if I argue against my own interests?-) anyway: - if you want explicitly declared, non-extensible records, you can use data type variants to tag anonymous records with fixed sets of labels (so anonymous records accomodate both user groups) - if you want type class interfaces that hide representation, will they be any easier to implement on top of labelled fields? it was investigation of this issue that led me away from TREX (the type of extension there forces you to name labels in the type, and type classes force you to make types more explicit than needed), and to approaches based on first-class labels - these questions, and more like them (eg., how to tag polymorphic components?), should be addressed when preparing labelled fields for replacement, as per Malcolm's suggestion; if you define a user-level view of records that can be implemented by either labelled fields or extensible records, then you have to account for typical usage patterns as well - if the committee follows Malcolm's suggestion, with my comments, implementations could, at some point, provide an implementation of records using Daan's system as an alternative to the current implementation.; it is possible that, in the process of defining the alternative translation into Daan's system, the committee finds that there is no point in keeping the old system around - in case you hadn't noticed: the Data.Record.hs attached to the first-class labels ticket does implement scoped labels in current Haskell+ (only ghc at the moment, I'm afraid, which is one reason why I'm after more coherence between implementations). it does not have Daan's simple types, because Haskell doesn't give me a commutative-associative type constructor, and I have to implement what would otherwise be a type-system extension via type classes (hence predicates in types). but for some of you, that's what you ask for anyway, and you do get record concatenation as a bonus;-) - once upon a time, there was paper after paper on optimizing pattern matching. but, in these days of heavy type-class programming, I could only name a single paper on optimizing type-classes. I remember one of the first talks on HLists, where the speaker said something like "advanced Haskell compilers will eliminate this type-class overhead statically" and the Haskell compiler implementers in the audience replied "what Haskell compilers? ours won't!". what about using the static properties of HLists, Data.Record, nested tuples, and so on, for generating constant time access, etc? any takers?-) cheers, claus