Records in Haskell
anthony_clayden at clear.net.nz
Tue Feb 28 09:57:58 CET 2012
wren ng thornton <wren <at> freegeek.org> writes:
> FWIW, this is the concern I alluded to earlier. Namely that we may want
> to have two (or more), er, 'classes' of records--- where a field is
> polymorphic over an individual class, but we don't want those classes to
> merge simply because they happened to choose the same name and type for
> the field.
I agree 'classes' is a misleading word for that. Isn't what you want two (or
more) namespaces for records -- that is, for their fields?
This is the DORF approach. (Barney seems to be describing the SORF approach --
he's got DORF wrong.)
One of the namespaces includes Product.name; another Person.name. (So I'm
taking a namespace as equivalent to a module.) You can have multiple records
with a `name` field in each module (Customer, Employee, Business Contact,
etc) -- so this is already better than H98.)
Providing you're coding in a module that imports only one of those namespaces,
you can use `name` unqualified.
If you're coding in a module that imports both, you must use `name` qualified.
If you try to apply (Product.name customer) you'll get a type failure (no
> I'm not sure it's a good proposal, but it seems like the only way to
> handle this issue is to (1) introduce a new kind for
> semantically-oriented field names,
That's what SORF does: the String Kind
> and (2) make the Has class use that
> kind rather than a type-level string.
No proposal is using a _type_-level string. Barney's confused you.
DORF uses a type (regular importable/qualifiable/hidable) with a prefix to the
Where you're in a module that imports both the `name`s per above, the
desugarrer would generate Product.Proxy_name and Person.Proxy_name.
(That's all rather awkward to get right, which is why I prefer the sugar.)
By (1), what I mean is that rather
> than referring to the field as "name", we would declare PersonalName and
> BrandName and then use those in lieu of the string. And if we do that,
> then (2) demands that we must somehow make explicit which one we mean,
> should we want the `name` field to be polymorphic for some given record
More information about the Glasgow-haskell-users