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 _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
