Hacker News Reader

Comment by bipvanwinkle | Hacker News Reader

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.

View on HN

Actually, 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-... [2] http://stackoverflow.com/questions/38136144/replace-record-p...

Most 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.

I'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.

I'm not sure how useful an introduction it is, but I really enjoyed this talk:

https://skillsmatter.com/skillscasts/4251-lenses-composition...

The 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!

On 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

I don't see how that's contrary to what the parent said.

I 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.

That'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.

I 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-Vi...

1: http://hackage.haskell.org/package/rawr-0.0.0.1/docs/Data-Ra...

I 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.

Reply on news.ycombinator.com