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

Adam Gundry adam.gundry at strath.ac.uk
Sat Apr 27 10:51:39 CEST 2013


Hi Petr,


On 26/04/13 19:53, Petr Pudlák wrote:
> Hi Adam,
> 
> very nice idea. As the others, I'm curious why you chose to implement
> SORF in favor of the other ideas?

As I've commented in a message just now [1], by mentioning SORF I didn't
mean to exclude taking on board the other proposals (particularly
DORF/TPDORF). I do think a type-based approach is the way forward, with
a new sort of constraint that gives a polymorphic type to record
projection. The plans based on changing the name-spacing rules either
need type-based resolution as well, or require field names to be
prefixed with the relevant data type (so they don't fully solve the
problem).

Also, I'm a type theorist, so obviously the type-based solution is the
best one. ;-)


> I just read the SORF proposal, and I'm a bit concerned about what error
> messages would GHC issue when someone would type incorrect code
> involving such records. Currently Haskell's error messages already pose
> a barrier for newcomers (like "No instance for (Num (a -> a))"), and if
> records are converted into those very complicated `Has` instances, type
> errors would be probably undecipherable even for moderate skilled
> Haskell users. Considering that records are a basic feature of Haskell
> and something that  people with OOP background are familiar with, this
> could result in a feature that would without doubts deter many (if not
> most) newcomers. So do you think it would be possible to implement it in
> such a way that users get sensible type error messages?

You're right to raise this as an issue. I think it is essential to get
good error messages, or at least no worse than we have already! Rather
than "No instance for Has r l t" we want it to say something like "Type
r has no field l".  This justifies special treatment of Has constraints
by the compiler, rather than simply desugaring to an encoding.
Constraint-based type inference means this shouldn't be too difficult.

The current description of SORF doesn't really distinguish between the
user's perspective and the implementer's. This is something that we
should change (so it's clear how much users will need to understand);
but perhaps I'll wait and see if my GSoC proposal is accepted first!


>   Best regards,
>   Petr

Thanks for your comments,

Adam

[1] http://www.haskell.org/pipermail/haskell-cafe/2013-April/107876.html



More information about the Haskell-Cafe mailing list