Records in Haskell

Oliver Batchelor saulzar at
Mon Feb 27 05:48:55 CET 2012

Hi Greg,

(Apologies for second mail, I didn't include the list)

I think the DORF approach is quite principled in it's namespacing. The
labels are just normal functions which can be exported and imported
between modules. I believe that is it's main strength - so I think to
say "it only solves the narrow name-spacing issue within a module." is
not quite accurate.

Sure - if you have two unrelated modules - say Data.Foo and Data.Bar
each with records with fields x and y they will clash. But this is a
very common situation e.g. how many functions called "map" are defined
in various modules?

If the modules are related, however - we can re-use the same label
without problem (in the same way we can define a type class Functor
for all the various "map" functions). I don't think it is so important
that we have globally common labels - if anything I would think that
would be an engineering goal to avoid? (Imagine how many labels called
"x" with different types may spring up)

-- First you create the labels:

module A (width, height)

width :: r { width :: Float } => r -> Float
height d :: r { height :: Float } => r -> Float

-- We can use them in one module.

module B (Rectangle (..)) where

import A (width, height)
data Rectangle = Rectangle { width, height }  -- Potentially don't
need to give these types, since they're already defined by the label

module C (Box (..)) where

import A (width, height)
length d :: r { length :: Float } => r -> Float

data Box = Box { width, height, length }  -- Use the same fields again

I've been following the discussion with interest.


On Mon, Feb 27, 2012 at 5:47 AM, Greg Weber <greg at> wrote:
> The DORF proposal is bringing to light some universal issues with
> records, so I am glad they are being hashed out. However, at this
> point it is premature optimization: we still don't have a proposal
> that solves the narrow issue of record name-spacing with Haskell.
> At this point SORF/DORF need a hero to figure out how to make them
> work with all of Haskell's current type capabilities. The DORF
> proposal makes some steps forward, but also backwards: it only solves
> the narrow name-spacing issue within a module. If a record is imported
> into another module, it will still clash.
> I stated this months ago, and I think it is even truer now: the sugar
> approach to records does not appear to actually be simplifying things,
> therefore we should consider adding a new first-class construct.
> I don't know much about the subject of first-class records, but so far
> I have come across a few styles of existing implementations in FP:
> structural typing, records as modules, and row types.
> I recently linked to Ur's extensible record impementation (that uses
> row types) from the wiki:
> We are trying to stay focused on the narrow issue of solving
> name-spacing. I think we can stay narrow if we do implement first
> class records but hold off for now on presenting any special
> capabilities to the programmer.
> At this point we are months into the records process without a clear
> way forward. I think we should be willing to take any workable
> implementation and just avoid exposing the implementation details for
> now. If anyone can lend a hand at figuring out SORF updates or
> determining if type inference of records in the Ur paper can be made
> to work in Haskell, that would be very helpful!
> Greg Weber
> On Sun, Feb 26, 2012 at 7:01 AM, Jerzy Karczmarczuk
> <jerzy.karczmarczuk at> wrote:
>> Barney Hilken :
>>> Haskel is supposed to be a theoretically sound, cleanly designed language,
>>> and if we lose sight of this we might as well use C++.
>> Well, since I have nothing to say about new records, I don't say anything,
>> but I have the impression that when we got to this level of discussion, it
>> is a beginning of the end. Veeery, very funny...
>> Imagine an ecclesiastic General Council, and the Pope saying:
>> "Brothers Bishops! Our new dogmas must be absolutely flawless, pure and
>> sound, otherwise we might as well become Muslims".
>> Inchaa whatever.
>> Jerzy Karczmarczuk
>> Caen, France
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list