Keep the present Haskell record system!

[Claus Reinke]

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