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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users