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