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

Evan Laforge qdunkan at
Wed Feb 24 15:21:30 EST 2010

On Wed, Feb 24, 2010 at 11:50 AM, John Meacham <john at> wrote:
> 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.

Ah, so to paraphrase, fields are just syntax sugar for an ADT + access
functions + update syntax.  Update syntax is just sugar for a "\b -> A
a _ c -> A a b c" expression.  Pure sugar.

Records are basically "anything more substantial than sugar" but may
imply a new "label" concept (i.e. not just reusing functions), literal
syntax, extensibility, type system support for subtyping, etc. etc.

This seems like a reasonable distinction.

More information about the Haskell-prime mailing list