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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe