[Haskell] Re: Re: RE: Extensible records: Static duck typing
b.hilken at ntlworld.com
Thu Feb 21 05:34:31 EST 2008
> My rationale for these criteria goes like this: efficient access is
> necessary if we want to compete with the much simpler record systems
> 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.
> 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.
More information about the Haskell