Hi Johan, On 26/04/13 20:46, Johan Tibell wrote:
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.
I'm the one busily opening this particular can. It's good to know it's an important one though! Thanks for characterising the problem so neatly:
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 () printId emp = print $ emp.id http://emp.id
Is that correct or do you have to replace 'Employee' with 'r { id :: Int }' in the type signature of 'printId'?
That's correct. The most general type (inferred if the annotation is omitted) will be something like printId :: r { id :: Int } => r -> IO () but you are free to declare a more specific type in the usual way, much as if the constraint was 'Show r', say.
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.
Thanks, I take your point. My proposal is to implement a good solution to the problem you've outlined; I don't think we should go all the way to extensible records just yet, if at all.
Cheers, Johan
All the best, Adam