5 ms·

>Take lenses for example. All of this unnecessarily complicated shit because Haskell doesn’t have any reasonable record syntax. Lenses (in the original, pre-La

>Take lenses for example. All of this unnecessarily complicated shit because Haskell doesn’t have any reasonable record syntax. Lenses (in the original, pre-Laarhoven form) are literally the same as properties in, say, C#. The extra complexity in their modern form is to pack the setter and getter into a single function, and allow in-place modification (without going throgh getter and then back through setter). The extra-extra complexity in the lens package is the result of Edward Kmett et al generalizing it to support traversals and pattern matching, while also providing support for the entire standard library and the kitchen sink. As for mutation, I agree. I think Rust with hihgher-kinded polymorphism would be my ideal language.

foldr 7y ago
There's always a reason of some kind for the additional complexity. The question is whether it's worth it. > The extra complexity in their modern form is to pack the setter and getter into a single function, and allow in-place modification (without going throgh getter and then back through setter In place updating of nested fields is pretty much the bare minimum that any respectable record system provides.
- antisemiotic 7y ago
  A record system doesn't allow to create fields from arbitrary getter-setter pairs. Lenses are an implementation of property system, not a record system. That the heavyweight solution is also used for regular records because Haskell's record syntax is broken is another matter. I still frequently wish I could use lenses in other languages, but they're hard to implement without HKT (I wouldn't be surprised if someone implemented them for Scala though). EDIT: And to clarify, by in-place updating I meant in-place semantically, not syntatically (the old solution of keeping a record of two functions can do the syntax part too). But I think I probably misremembered how van Laarhoven lenses work and they might not be ultimately different from getter-setter chaining, sorry.

foldr 7y ago

There's always a reason of some kind for the additional complexity. The question is whether it's worth it. > The extra complexity in their modern form is to pack the setter and getter into a single function, and allow in-place modification (without going throgh getter and then back through setter In place updating of nested fields is pretty much the bare minimum that any respectable record system provides.

antisemiotic 7y ago
A record system doesn't allow to create fields from arbitrary getter-setter pairs. Lenses are an implementation of property system, not a record system. That the heavyweight solution is also used for regular records because Haskell's record syntax is broken is another matter. I still frequently wish I could use lenses in other languages, but they're hard to implement without HKT (I wouldn't be surprised if someone implemented them for Scala though). EDIT: And to clarify, by in-place updating I meant in-place semantically, not syntatically (the old solution of keeping a record of two functions can do the syntax part too). But I think I probably misremembered how van Laarhoven lenses work and they might not be ultimately different from getter-setter chaining, sorry.