Dear all, I'm increasingly convinced that the records should be left alone for Haskell', possibly modulo some minor tweaks to polish the system. While there are a number of reasonable proposals out there for a replacement record system, and while I do agree that a more flexible system would be desirable, there just is no consensus whatsoever as to which one is the way forward. Moreover, my impression is that maintaining backwards compatibility while truly addressing the shortcomings of the present system, almost inevitably would lead to a language with TWO kinds of records. I must say I really don't like that prospect. If the above is true, then that would imply that backwards compatibility would have to be sacrificed in a serious way if we were to move forward with a proposal for a new record system. I don't think there is a case for this in the context of Haskell'. A while ago, I suggested some rules-of-thumb for when serious backwards-compatibility breaking changes might be considered for Haskell'. To recap: If a proposed change breaks backwards compatibility, then it is acceptable only if either 1. very little existing code is likely going to be broken in practice, or 2.1. it is widely agreed that not addressing the issue really would harm the long-term relevance of Haskell', and 2. it is widely agreed that attempting to maintain backwards compatibility would lead to an unwieldy language design, and 3. the proposed design and its implications are well understood, i.e. it has been implemented in at least one system and it has been used extensively, or a strong argument can be made on the grounds of, say, an underlying well-understood theory. From the people who commented on that, there seemed to be some support for this position, and no one, as far as I know, said they thought that the above was too restrictive. My position is that two parallel record systems is so unwieldy so as to not be acceptable. That would imply that fixing the records would break lots of code. That means rule 1 above does not apply. One can probably find some proposals out there that meet criteria 2.3. However, I don't think 2.1 can be argued convincingly. Yes, some people claim that no proper records is the key thing that gets in the way of serious software development in Haskell. I don't believe that as I see lots of serious Haskell software out there that seems to have been developed just fine with the existing records (or not using records at all, or using some kind of "home brewed" records.) (In contrast, it seems to me that lots of serious Haskell software out there do use MPTCs, FDs, and rank-2 or higher types.) Moreover, I think the current record system is being unfairly discredited. Yes, it is certainly not perfect. But by adopting some simple conventions for naming fields to avoid name clashes, it is really not that hard to use them in the way records are used in a language like, say, C. (No, I'm not arguing that C's record system is great, just that that basic kind of records evidentially is enough for supporting some really serious software development efforts.) Moreover, there is scope for improving the present system a little bit without any major changes. Anyway, the present records certainly beats having no records at all hands down, and they are moreover very lightweight and fits very nicely into Haskell. For this, they deserve credit. My proposal is thus that we move forward on records for Haskell' by deciding to essentially keep the current record system. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.