My stance is that it is possibly better if we do not try to include a one-size-fits-it-all record system into the language, but if the language provided support for basic things that almost all record system *libraries* would need.
Agreed. To the extent that such libraries could be improved by sugar, a general solution for such library-specific sugar might be sought. But the record libraries tended to be quite useful, modulo (of the top of my head, probably incomplete): - first-class labels I wonder whether the recent lifting of values into the type-level (towards typed types) offers sufficient convenience? Do they address the sharing issue? Haven't had the time to read yet; - soundness All the type-class based libraries work in the grey area of things that GHC allows for pragmatic reasons and that Hugs disallowed for soundness reasons; the success of GHC shows that Hugs was too careful, but I'd prefer if GHC either acquired safe features that could replace the current interplay of FDs and Overlapping Instances, or if someone proved the set of features in use safe; - optimization there is no reason why record libraries need to be slow to run, and the compilation time increases needed to make it so might be optimized away, too; but someone needs to do the work, or record field selection will -naively and in overloaded style- involve linear lookup; If these were to be addressed, record libraries would be more widely acceptable than they are today (though I recommend playing with the ones that exist, and reporting on their strengths and weaknesses in practice); initially, everyone would use their favorite, but I am hopeful that a common API would emerge eventually, from use. We haven't had any luck agreeing on a common API before use, and none of the many good proposals have managed to sway everyone, which is why I agree on not settling on a single design just yet - just pave the road for wider adoption of record libraries). Back to the side-line for me;-) Claus