I think this would be a BIG mistake. Whatever system GHC settles on is almost certain to become part of the Haskell standard, and this particular system has some deep limitations which could not be got round without ripping it all out and starting again. The problem with this (and other "Flex-like") systems is that they take record extension as the basic operation of record building, rather than record merging. This means that you can only ever add or update statically determined fields of a given record. An important application which is made impossible by this approach is functions with optional arguments. For example, if you look at the definition of R (the statistics system) every function has a small number of mandatory positional arguments, and a very large number of optional named arguments, which take sensible default values. I want to be able to write:
f opts x = let vals = {Opt1 =: default1, ... } |: opts in ... vals ... x ...
where '{Opt1 =: default1, ... }' is some fixed record of default values, and '|:' is record overwrite. The type of f should be
f :: (a `Subrecord` {Opt1 :=: t1, ...}) => a -> b -> c
where '{Opt1 :=: t1, ...}' is the (fixed) type of '{Opt1 =: default1, ... }' (and x::b, and c is the type of the result). The condition 'a `Subrecord` {Opt1 :=: t1, ...}' in the context of this type means that every field of 'opts :: a' must be a field of '{Opt1 :=: t1, ...}', but opts can have as few fields as you like. This is exactly what you want for optional arguments. This could never be defined in any "Flex-like" system, because these systems depend on the fact that their record types can be reduced to a type variable extended by a fixed set of labels. This is a major restriction to what you can do with them: you can never define operations like '|:' or '+:' where the second argument does not have a constant set of fields. This restriction does not hold for more flexible systems like that defined by Oleg & co using functional dependencies, or the one I proposed on this list using type families. Although these systems are much more flexible than the "scoped labels" system, they would take LESS work to add to GHC because they have less built-in syntax, and are almost entirely defined in a library. I second the call for a records system, but please don't limit us to something like scoped labels! Barney.