[Haskell] RE: Extensible records: Static duck typing

[Ben Franksen]

Simon Peyton-Jones wrote:
> Since you are taking my name in vain, I had better respond!  I wish I felt
> as confident of my good taste as you do. My last attempt to implement
> records (with Umut Acar, more or less the design in the "proposal for
> records" paper) involved rather significant changes to the type checker,
> and I was reluctant to commit to them without stronger evidence that it
> was a good design.

What about just implementing the cheapest solution that still gets us most
of the way? 

Yes, I mean yours:
http://research.microsoft.com/~simonpj/Haskell/records.html

"...It is a little less expressive than the earlier proposal, but (a) it is
considerably simpler to implement, and (b) it is rather simpler to explain.
In particular, we can translate source programs using records into System
Fw, GHC's existing, strongly-typeed intermediate language. This is a major
benefit, because it means that the existing transformations and
optimisations in GHC's middle end can remain unchanged."

I am suggesting that this proposal gets implemented in GHC.

(1) Lack of records is biting me every day, literally. There is NOTHING that
is missing from Haskell (the language) as much as (extensible) records.

(2) You already thought about it. You think it is easier to implement than
other, more ambitious, proposals. This means chances are great that we can
ACTUALLY HAVE something in the not too distant future instead of debating
the issue until hell freezes over.

(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.

(4) An implementation that can be evaluated opens the road to
standardization in Haskell' (its motto being that only tried and
implemented features go in).

(5) Don't underestimate the psychological effect this would have. I am dead
certain that many, many people would immediately jump on the train and use
them in their code, limitations or not. I certainly would.

The article lists some open questions. I want to chime in and propose that
you decide them at your leisure. If in doubt, chose the solution that is
easier to implement. If this doesn't help, post specific questions on the
list and ask for opinions, then let majority of interested people decide.

The important thing is to have something real to start experimenting with.

Cheers
Ben