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

Johan Tibell johan.tibell at gmail.com
Fri Apr 26 21:46:40 CEST 2013


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 ()
    printId emp = print $ emp.id

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130426/ccdc3939/attachment.htm>


More information about the Haskell-Cafe mailing list