Evan Laforge
[ ccing the list because the wiki page was flawed and I made a bunch of changes, hope you don't mind ]
Thanks Evan, I've had a quick read through. It's a bit difficult to compare to the other proposals. I can't see discussion of extracting higher-ranked functions and applying them in polymorphic contexts. (This is SPJ's `rev` example.) Putting h-r fields into records is the standard way of emulating object- oriented style. SPJ's view is that requirement is "very important in practice". (No proposal has a good answer to updating h-r's, which you do discuss.) Re the cons 1. "Still can't have two records with the same field name in the same module since it relies on modules for namespacing." Did you see the DORF precursor page ? http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... /NoMonoRecordFields I tried to figure out if that would help, but I suspect not. (Looking at the desugar for `deriving (Lens)`, you need the H98 field selector functions.) Then for me, cons 1. is a show-stopper. (I know you think the opposite.) I also don't see whether you can 'hide' or make abstract the representation of a record type, but still allow read-access to (some of) its fields. Suppose a malicious client declares a record with field #a. Can you stop them reading and/or updating your field #a whilst still letting them see field #b of your record type? With SDNR, is it possibly to define a polymorphic field selector function? I suspect no looking at the desugar for `deriving (Lens)`, but perhaps I've mis- understood. I mean: get_a r = ?? #a r -- gets the #a field from any record r This mechanism then supports the idea of 'virtual' fields -- SPJ's example of fullName, built from polymorphic firstName and lastName. [By the way, did you mean to post to the cafe only? Most of the discussion is going on on ghc-users.] AntC