On Wed, Feb 24, 2010 at 11:50 AM, John Meacham <j...@repetae.net> 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 <j...@repetae.net> 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. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime