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

[Ben Franksen]

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