RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields

John Meacham john at
Wed Feb 24 14:50:58 EST 2010

On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote:
> On Wed, Feb 24, 2010 at 11:03 AM, John Meacham <john at> wrote:
> > This isn't so much a proposal as a recommendation for terminology we use
> > when talking about things on the list and proposals in general. Calling
> > haskell's labeled field mechanism 'records' leads to all sorts of
> > confusion for people that come from other languages where 'records'
> > means something else, this is compounded by the fact there are several
> > actual record proposals out there that are orthogonal to labeled fields,
> > but calling fields 'records' confuses this issue.
> Just out of curiosity, what are the attributes associated with
> "labeled fields" and what are the ones associated with "records"?

Well, when you have a data constructor like

data Foo = Foo Int Char

your Int and Char are the two fields of your data constructor Foo,
labeled fields are exactly that, a way to refer to them by labels rather
than positionally. in particular, the run-time implementation and
ability for optimization is exactly the same. it is simply a more
convienient way to work with a construct that already exists in Haskell
with no overhead, like a newtype.

A record system generally implies labels that can be easily re-usued between
different types and is extensible in nature. They may not need to be
pre-declared. Allowing these may require compromises at run-time
creating a tension between their utility and performance. I like to think
of them more analogous to tuples with labels than declared data types.
Of course, not all record proposals for haskell embody the exact same
thing, but these features seem to be what people coming to haskell
expect out of something called a 'record' system and are more or less
what the various proposals provide.


John Meacham - ⑆⑆john⑈ -

More information about the Haskell-prime mailing list