News for hackers. Stuff that matters.
Re:Reflecting on Haskell in 2016 by bipvanwinkle on Monday December 26, 2016 @12:09AM (#13257035)
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.
Re:Reflecting on Haskell in 2016 by harpocrates on Monday December 26, 2016 @12:49AM (#13257155)
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...

Re:Reflecting on Haskell in 2016 by wyager on Monday December 26, 2016 @12:23AM (#13257081)
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.
Re:Reflecting on Haskell in 2016 by axman6 on Monday December 26, 2016 @02:59AM (#13257427)
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
Re:Reflecting on Haskell in 2016 by dllthomas on Monday December 26, 2016 @03:17AM (#13257471)
I don't see how that's contrary to what the parent said.
Re:Reflecting on Haskell in 2016 by axman6 on Wednesday December 28, 2016 @05:50AM (#13269735)
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.
Re:Reflecting on Haskell in 2016 by dllthomas on Wednesday December 28, 2016 @10:18AM (#13270992)
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.

Re:Reflecting on Haskell in 2016 by bipvanwinkle on Monday December 26, 2016 @12:46AM (#13257144)
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.
Re:Reflecting on Haskell in 2016 by dllthomas on Monday December 26, 2016 @03:04AM (#13257445)
I'm not sure how useful an introduction it is, but I really enjoyed this talk:

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

Re:Reflecting on Haskell in 2016 by greenrd on Monday December 26, 2016 @07:04AM (#13257963)
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!
Re:Reflecting on Haskell in 2016 by codygman on Monday December 26, 2016 @12:18PM (#13258924)
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...

Re:Reflecting on Haskell in 2016 by dllthomas on Monday December 26, 2016 @01:15PM (#13259146)
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.