[Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Adam Gundry]

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