Simon Peyton-Jones wrote:
Since you are taking my name in vain, I had better respond! I wish I felt as confident of my good taste as you do. My last attempt to implement records (with Umut Acar, more or less the design in the "proposal for records" paper) involved rather significant changes to the type checker, and I was reluctant to commit to them without stronger evidence that it was a good design.
What about just implementing the cheapest solution that still gets us most of the way? Yes, I mean yours: http://research.microsoft.com/~simonpj/Haskell/records.html "...It is a little less expressive than the earlier proposal, but (a) it is considerably simpler to implement, and (b) it is rather simpler to explain. In particular, we can translate source programs using records into System Fw, GHC's existing, strongly-typeed intermediate language. This is a major benefit, because it means that the existing transformations and optimisations in GHC's middle end can remain unchanged." I am suggesting that this proposal gets implemented in GHC. (1) Lack of records is biting me every day, literally. There is NOTHING that is missing from Haskell (the language) as much as (extensible) records. (2) You already thought about it. You think it is easier to implement than other, more ambitious, proposals. This means chances are great that we can ACTUALLY HAVE something in the not too distant future instead of debating the issue until hell freezes over. (3) If it is as cheap (to implement) as advertised then there is no great risk involved. If it turns out the missing features are a great show-stopper for some people (which I don't believe) then let them present their case afterwards, with good examples at hand. We can still decide to aim for a higher goal in the long term. (4) An implementation that can be evaluated opens the road to standardization in Haskell' (its motto being that only tried and implemented features go in). (5) Don't underestimate the psychological effect this would have. I am dead certain that many, many people would immediately jump on the train and use them in their code, limitations or not. I certainly would. The article lists some open questions. I want to chime in and propose that you decide them at your leisure. If in doubt, chose the solution that is easier to implement. If this doesn't help, post specific questions on the list and ask for opinions, then let majority of interested people decide. The important thing is to have something real to start experimenting with. Cheers Ben