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

Ben Franksen ben.franksen at online.de
Sun Feb 10 15:02:36 EST 2008

[redirecting discussion from @haskell to @cafe]

Barney Hilken wrote:
>> What about just implementing the cheapest solution that still gets
>> us most
>> of the way?
>> (3) If it is as cheap (to implement) as advertised then there is no
>> great
>> risk involved. If it turns out the missing features are a great
>> show-stopper for some people (which I don't believe) then let them
>> present
>> their case afterwards, with good examples at hand. We can still
>> decide to
>> aim for a higher goal in the long term.
>> If in doubt, chose the solution that is easier to implement.
> Since this paper, there have been several proposals which can be 90%
> implemented as libraries, using either functional dependencies or
> associated types. These all have much more expressive type systems
> than the SPJ paper, yet need very little compiler support. The
> question is, which one (if any) should get this small but necessary
> support?

Which proposals exactly do you refer to?

Where can I read about the amount of compiler support these proposals need
to make them practically usable?

I know about HList/OOHaskell papers+library. This is very interesting stuff
but it is not something that comes even close to being usable in day-to-day
programming. It is too hard to understand, the (type) error messages are
completely uncomprehensible, it is completely unclear how to to make it
efficient and how much compiler support would be needed to overcome all
these problems.

Besides, the question of "functional dependencies or associated types" is
still open, right?

I think it would be a very bad idea to wait until all those issues have been

So, unless there are other library based proposals on the table that I am
not aware of and which don't share these problems, I still think the
proposal I was referring to
(http://research.microsoft.com/~simonpj/Haskell/records.html) comes closest
to what people want and need, while still requiring minimal implementation


More information about the Haskell-Cafe mailing list