4 ms·
Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, bu
by bipvanwinkle 10y ago
Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, but it looks like it has stalled out.
- wyager 10y agoMost people use Lenses for heavily record-oriented programming. They work quite well. They are less convenient than built-in structural syntax like in Javascript, but once you get past the initial inconvenience they are vastly more powerful.
- bipvanwinkle 10y agoI'll need to check out lenses. I've run in to a few annoying this working with records so far so I was hoping some progress was in the works.
- dllthomas 10y agoI'm not sure how useful an introduction it is, but I really enjoyed this talk: https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation https://skillsmatter.com/skillscasts/4251-lenses-composition...
- greenrd 10y agoThe main lens library in Haskell doesn't exactly have no documentation, but it is pretty much impenetrable without a third-party tutorial or blog post. But persevere - it's really powerful!
- axman6 10y agoOn the contrary, lenses are far more powerful than what's available in JavaScript and all other OO languages. Traversals and Prisms give so much power that's lacking in OO
- dllthomas 10y agoI don't see how that's contrary to what the parent said.
- axman6 10y agoI guess that my point was that for the situations where the built in syntax in OO languages is used, the lens alternative is usually at most about 2 characters longer, which is hardly more inconvenient.
- dllthomas 10y agoThat's a point, just one that was entirely missing from your previous comment. That said, it's not just use. You've also gotta deal with some additional imports, and with defining your lenses. For the simplest case, that's a bit of overhead compared to having it all baked in.
- harpocrates 10y agoActually, a lot has been done and a lot is coming in the near future. GHC 8.0 brought us `DuplicateRecordFields`, so that we can finally use the same field name for two records. There is active work done by Adam Gundry to extend this even further [1]. The key part of this is that there will be a new type class so that I can express as a constraint that a type must have a field with a certain name and with a certain type. Further in the future, but still actively discussed is using overloaded labels as lenses [2]. Past that, I can't imagine anything else I would want records to do. [1] https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst https://github.com/adamgundry/ghc-proposals/blob/overloaded-... [2] http://stackoverflow.com/questions/38136144/replace-record-projection-function-with-lenses http://stackoverflow.com/questions/38136144/replace-record-p...
- codygman 10y agoI use Vinyl[0], though be warned it uses advanced Haskell many seem disgruntled with in this thread. You may be alright with vanilla Haskell records now that duplicate record fields are allowed in GHC 8. I think something like rawr[1] might be what most are looking for when talking about better Haskell records, though. 0: https://hackage.haskell.org/package/vinyl-0.5.3/docs/Data-Vinyl-Tutorial-Overview.html https://hackage.haskell.org/package/vinyl-0.5.3/docs/Data-Vi... 1: http://hackage.haskell.org/package/rawr-0.0.0.1/docs/Data-Rawr.html http://hackage.haskell.org/package/rawr-0.0.0.1/docs/Data-Ra...
- dllthomas 10y agoI find the ergonomics of records with RecordWildCards great for most of my uses. Nested records in Haskell are still a pain if you're trying to do things to internal bits directly - that's what lenses address.