Records in Haskell

[AntC]

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 
instance).



> 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 
field name:
    data Proxy_name

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 
> declaration.
> 

AntC