Hi Adam, very nice idea. As the others, I'm curious why you chose to implement SORF in favor of the other ideas?
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? Best regards, Petr 2013/4/26 Adam Gundry <adam.gun...@strath.ac.uk> > Hi, > > I am hoping to do a GSoC project this year working on GHC, and have been > pointed in the direction of the records issue (in particular, the desire > to overload field names). This has been discussed on-and-off for years, > and while there are lots of ideas [1], little has been implemented in > GHC itself. > > The plan would be to implement a solution to the "narrow issue" of > overloaded field names, along the lines of Simon PJ's SORF proposal (on > the wiki). This would provide a basis for experimentation with > first-class record types. While there are still design issues to > resolve, the broad plan is clear and I'm confident it can be implemented > in a summer and without overly restricting future record system designs. > > Does this sound like a reasonable strategy? I'd appreciate comments and > criticism, although arguing about the details of the design should > perhaps wait. > > (A little about me: I'm a PhD student working on type inference for > Haskell and dependent types, with about four years' Haskell experience > including work on big type-system related projects. I am familiar with > the theory behind GHC, but I haven't worked on the code before.) > > Thanks, > > Adam Gundry > > > [1] http://hackage.haskell.org/trac/ghc/wiki/Records > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe