Barney Hilken
My objection is that I'm not sure if there is ever a case where "you really want things to be polymorphic over all records".
Well, I don't have a simple, really convincing example, but there are
More importantly, DORF automatically attaches one class to each label, but
certainly things I want to play with. this is often not what you want. Barney, you seem to be very confused. Added to that you're mixing up DORF with SORF. Agreed both proposals are similar, but there are crucial differences and you've completely befuddled them. In DORF (and SORF) there is only one class -- namely `Has`, with methods `get` and `set`. SORF 'attaches' one Kind for each label. (I'm not sure 'attaches' is the right word -- perhaps 'provides' is better? It's a String Kind same as the label name.) In DORF you must _declare_ a _type_ for the label. (Hence "**Declared** Overloaded Record Fields".) Since it's declared and it's a type, it has usual namespace (module) control. You can declare as many as you want, providing you respect the namespacing.
For example, if you have two fields "firstname" and "lastname" the associated classes are less useful: what you really want is
class (Has r "firstname" String, Has r "lastname" String) =>
HasPersonalName r
That example is a SORF declaration: it uses String Kinds. The DORF equivalent would be: class (Has r Proxy_firstname String, Has r Proxy_lastname String) => HasPersonalName r Note: familiar Haskell proxy types, _not_ new/untried String Kinds. That Proxy stuff is a mouthful, and easy to mistype. I prefer the sugar: class (r{firstname, lastname :: String} ) => ...
so that you can define
fullname :: HasPersonalName r => r -> String fullname r = r.firstname ++ " " ++ r.lastname
You may also want to define subclasses to express more specific conditions. In general, the compiler cannot automatically deduce what is semantically important: you need to define it yourself. The Has class is the base on which you can build.
...
My approach achieves the same as DORF (and more), but using existing language features instead of introducing new ones.
Barney.
What you say there applies to SORF, not DORF. DORF deliberately uses existing class features and familiar type instance resolution. (Because I didn't like the 'experimental' Kinds in SORF, and you couldn't control their namespace.) So what you call "My approach" is almost identical to DORF -- except that you're confusing it with SORF syntax. What you're criticising is SORF, not DORF. AntC