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

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