Hi Adam,
Since we have already had *very* long discussions on this topic, I'm worried that I might open a can of worms be weighing in here, but the issue is important enough to me that I will do so regardless.
Instead of endorsing one of the listed proposals directly, I will emphasize the problem, so we don't lose sight of it. The problem people run into *in practice* and complain about in blog posts, on Google+, or privately when we chat about Haskell over beer, is that they would like to write a record definition like this one:
data Employee = Employee { id :: Int, name :: String }
printId :: Employee -> IO ()
printId emp = print $ id emp
but since that doesn't work well in Haskell today due to name collisions, the best practice today is to instead write something like:
data Employee = Employee { employeeId :: Int, employeeName :: String }
printId :: Employee -> IO ()
printId emp = print $ employeeId emp
The downsides of the latter have been discussed elsewhere, but briefly they are:
* Overly verbose when there's no ambiguity.
* Ad-hoc prefix is hard to predict (i.e. sometimes abbreviations of the data type name are used).
The important requirement, which might seem a bit obvious, is that any solution to this problem better not be *even more* verbose than the second code snippet above. If I understand the SORF proposal correctly, you would write:
data Employee = Employee { id :: Int, name :: String }
printId :: Employee -> IO ()
Is that correct or do you have to replace 'Employee' with 'r { id :: Int }' in the type signature of 'printId'?
The discussions about an overhauled record system also involve lots of talk about record sub-typing, extensible records, and other more advanced features. I'd like to point out that there doesn't seem to be a great demand for these features. They might be nice-to-haves or might fall out naturally from a solution to the namespacing problem above, but they are in fact not needed to solve the common problem people have with the Haskell record system.
Cheers,
Johan