Records in Haskell

[Gábor Lehel]

2012/2/25 Gábor Lehel <illissius at gmail.com>:
> Please correct me if I've misunderstood or mischaracterized any aspect of DORF.

Okay, I did end up misunderstanding and mischaracterizing at least two
aspects of DORF.

Re-reading the wiki page:

http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields

it's clear that you would not have to write fieldLabel declarations
for every single field of every single record, only for the ones you
wish to be shared and usable polymorphically. By default, fields of
individual records would be specific to that record (monomorphic in
the type of the record), except if there is a fieldLabel declaration
for them in scope in which case they would be considered instances of
it. (I hope I have it right this time...)

So the difference between DORF and my variant would be:

DORF: Fields are record-specific (monomorphic in the record type) by
default; having a field be polymorphic requires writing a fieldLabel
declaration and having it in scope when the record is declared; if a
matching fieldLabel is in scope the field is automatically considered
shared and polymorphic in the record type. In other words, you have to
write the "classes" explicitly, but the "instances" are inferred
automatically.

Me: Declaring a record always implies fieldLabel declarations for each
of its fields (record-specific, monomorphic-in-the-record-type fields
are not possible); these are always *new* fieldLabels, which are not
considered to be the same as previous ones and cannot be used
interchangeably with them; to re-use an existing fieldLabel for a
field of your record you must use explicit syntax. In other words,
here the "classes" are automatic, but the "instances" are explicit.

It wasn't clear to me before that DORF retains record-monomorphic
fields, while my variant does away with them. In DORF you can
presumably still use a record-monomorphic field selector to help infer
the concrete type of the record (whereas with polymorphic fields
inference goes in the other direction). Also, while in both variants
it is possible to avoid re-using an existing "field class" for your
record, in my variant it's not possible to prevent a downstream record
from re-using your "field class" (whereas record-monomorphic fields by
definition can't have further instances). So in effect in DORF inside
of record declarations you can have two types of fields,
record-polymorphic and record-monomorphic, along with separate
top-level fieldLabel declarations to declare which ones are the
polymorphic fields; while in my variant inside of records you can have
two types of fields, "classes" and "instances", with explicit syntax
to indicate which ones are the instances. Retaining record-monomorphic
fields seems like a flexibility-versus-consistency tradeoff: in DORF
you have two types of fields with opposite behaviour with respect to
type inference, whereas with my variant you only have one.

One troubling consequence of DORF -- again, if I'm understanding
things correctly -- is that due to implicit field instances a module
import can change the meaning of your program: a record field which
was considered record-monomorphic for lack of a matching fieldLabel
declaration will be considered polymorphic is one is imported. My
variant avoids this.

The other aspect of DORF which I mischaracterized in my previous email
is that fieldLabel declarations don't look like

fieldLabel name :: Text

rather, they look like

fieldLabel name :: r -> Text

where r stands for the type of the record. The implications of this
are not clear to me. As Henrik's email helped me realize, I'm
completely clueless with regards to how type variables are scoped and
handled in DORF. I also don't know how my proposed modifications would
affect it. So I'll go back to reading the wiki some more and let
Anthony field Henrik's questions in the meantime, if he wants to. (One
thing that's obvious is that universally quantified polymorphic fields
*are* allowed in DORF, because a specific example is listed which uses
one. It's completely inconceivable to me that any record system
proposal could be adopted which required doing away with them.
Complete show-stopper.)