[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 resolved. 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 effort. Cheers Ben