[Haskell] Re: Re: RE: Extensible records: Static duck typing

Barney Hilken 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  
> 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.


More information about the Haskell mailing list