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. 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 -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/