Records in Haskell

Anthony Clayden anthony_clayden at
Sat Jan 28 10:41:42 CET 2012

> On Thu, Jan 26, 2012 at 8:02 PM, AntC
> <anthony_clayden at> wrote:
> > Ryan Newton <rrnewton <at>> writes:
> >
> > >
> > > I admit I'm a big fan of polymorphic extension.  But I
> > don't love it enough
> > for it to impede progress!
> >
> Records proposals for Haskell have repeatedly foundered on
> the rocks of extensibility.  Meanwhile, it seems like
> years of experience with field extensibility in OO
> languages has shown that it's not an especially good idea,
> with authors on programming practice militating for
> information hiding instead.
> I don't think it's worth treading that path yet again in
> Haskell.
> -Jan

Jan, I agree we shouldn't try leaping forward to
extensibility yet. I disagree that we should abandon any
thoughts of it and produce a stopgap approach for records
that won't ever be extensible.

The 'proof of concept' I posted to the list last month
already includes get and set over polymorphic records and
polymorphic fields, I believe, which is half way there.

I love Haskell for the way it learns from well-structured
mathematical approaches -- in the way I feel OO doesn't.
There is a well-structured mathematically sound approach for
extensibility, as it happens. It dates back to 1969. It is
the 'engine' behind large-scale programming systems all over
the world every day. I do and have worked with a lot of

It's called Relational Algebra, it's based on set theory,
it's declarative - which should fit smoothly with Haskell.
It has an operation to extend records called 'extend' (!).
It has an operation to merge records called 'join'. It has
an operation to concatenate records called 'cross-product'

You'll probably know it by its 'awkward cousin' SQL. There
are many reasons for hating SQL, and there are many reasons
why it's a bad fit to OO -- especially because SQL is

There are many reasons to go back to the better-founded
mathematical basis that pre-dates SQL.


More information about the Glasgow-haskell-users mailing list