Barney Hilken wrote:
My rationale for these criteria goes like this: efficient access is necessary if we want to compete with the much simpler record systems in mainstream languages. If records are not as light-weight (syntactically as well as wrt run-time performance) as 'normal' Haskell data types, then people will be reluctant to use them, especially in library APIs. Finally, having to wait for highly experimental additional extensions to be available, tried, and tested, would only help to indefinitely post- pone the introduction of a usable record system.
I totally disagree. The great strength of Haskell is that, whenever important design decisions have been made, the primary consideration has not been practicality, but generality and mathematical foundation. When the Haskell committee first started work, many people said lazy evaluation was an academic curiosity: mathematically right, but far too inefficient for real programs. When Haskell adopted type classes, people said they were far too heavy a machinery to solve the relatively simple problems of equality, show and numbers. In each case the more general, abstract approach has shown enormous advantages in the long term. I'm sure the same will be true of associated types, which are a lot more complex than functional dependencies, but also more general, and more mathematical.
Just to make that point clear: I am not in any way opposed to associated types, I agree thet they are nicer than fundeps. And anyway experimental extensions are Haskell's bread and butter. I just had the impression that they are very new and that not all the issues surrounding them have been solved.
My criteria for choosing a record system would be: continue with the philosophy which has served Haskell so well up to now. In other words, choose the system which is most general and most mathematically sound; get some kind of implementation working so that we can get some experience with using it; then worry about efficiency later.
You are making a good point. Indeed, I feel like getting my own words thrown back to me, as I have often been arguing against 'practical' proposals with similar arguments. It reassures me a little bit that you are so convinced your library / associated types based proposal is actually better than the simple but admittedly more ad-hoc solution like SPJ's old proposal. I still fear that, better or not, appropriate support for your proposal will not be implemented in the forseeable future. So, maybe I just have to be more patient and wait yet another few years for Haskell records. Cheers Ben