Isaac Dupree
In the meantime, I had an idea (that could work with SORF or DORF) :
data Foo = Foo { name :: String } deriving (SharedFields)
The effect is: without that "deriving", the declaration behaves just like H98.
(For super flexibility, allow to specify which fields are shared, like "deriving(SharedFields(name, etc, etc))" perhaps.)
Is it too verbose? Or too terrible that it isn't a real class (well, there's Has...)?
-Isaac
Thanks Isaac, hmm: that proposal would work against what DORF is trying to do. You're right about the `deriving` syntax currently being used for classes. The fact of re-purposing the surface syntax is really no different to introducing different syntax. Apart from that, it might work for SORF -- and fall into exactly what I don't like about SORF, which is that it sabotages the namespace/module control that applies for every other user-defined name in Haskell. What you're not getting is that DORF quite intentionally helps you hide the field names if you don't want your client to break your abstraction. So under your proposal, a malicious client could guess at the fieldnames in your abstraction, then create their own record with those fieldnames as SharedFields, and then be able to update your precious hidden record type. And guessing the fieldnames is dead easy if you've exported the field selector function, to allow read-only access -- or so you thought. Under DORF, despite the client guessing the fieldnames, they can't use them at all if you don't export them -- because they're in a sealed-off namespace, just like regular Haskell. AntC