4 ms·

I definitely agree for traversals, but Lenses need some sort of primitive support - even in Haskell they're mostly generated with TemplateHaskell, and the langu

by T-R 1y ago

I definitely agree for traversals, but Lenses need some sort of primitive support - even in Haskell they're mostly generated with TemplateHaskell, and the language developers have spent a long time trying to make the `record.field` accessor syntax overloadable enough to work with lenses[1][2]. Hopefully someday we'll be free from having to memorize all the lens operators. Optics are famously abstract in implementation, but I don't think people have trouble applying them - people seem to like JQuery/CSS selectors, and insist on `object.field` syntax; it's kind of wild that no mainstream language has a first-class way to pass around the description of a location in an arbitrary data structure. [1] https://ghc-proposals.readthedocs.io/en/latest/proposals/0023-overloaded-record-fields.html https://ghc-proposals.readthedocs.io/en/latest/proposals/002... [2] https://ghc-proposals.readthedocs.io/en/latest/proposals/0158-record-set-field.html https://ghc-proposals.readthedocs.io/en/latest/proposals/015...

aozgaa 1y ago
Like offsetof[1]? [1] https://en.cppreference.com/w/cpp/types/offsetof https://en.cppreference.com/w/cpp/types/offsetof
- T-R 1y ago
  Optics let you concisely describe the location, but defer the dereferencing, so you could definitely approximate optics, not by passing around pointers you compute with `offsetof`, but passing around functions that use `offsetof` to return memory locations to reference (read/write to). You could certainly write a composition operator for `*(*T) => List<*R>`... Some people have done something like it[1][2]: Account acc = getAccount(); QVERIFY(acc.person.address.house == 20); auto houseLens = personL() to addressL() to houseL(); std::function<int(int)> modifier = [](int old) { return old + 6; }; Account newAcc2 = over(houseLens, newAcc1, modifier); These also use templating to get something that still feels maybe a little less ergonomic than it could be, though. [1] https://github.com/graninas/cpp_lenses https://github.com/graninas/cpp_lenses [2] https://github.com/jonsterling/Lens.hpp https://github.com/jonsterling/Lens.hpp

by T-R 1y ago

aozgaa 1y ago

Like offsetof[1]? [1] https://en.cppreference.com/w/cpp/types/offsetof https://en.cppreference.com/w/cpp/types/offsetof

T-R 1y ago
Optics let you concisely describe the location, but defer the dereferencing, so you could definitely approximate optics, not by passing around pointers you compute with `offsetof`, but passing around functions that use `offsetof` to return memory locations to reference (read/write to). You could certainly write a composition operator for `*(*T) => List<*R>`... Some people have done something like it[1][2]: Account acc = getAccount(); QVERIFY(acc.person.address.house == 20); auto houseLens = personL() to addressL() to houseL(); std::function<int(int)> modifier = [](int old) { return old + 6; }; Account newAcc2 = over(houseLens, newAcc1, modifier); These also use templating to get something that still feels maybe a little less ergonomic than it could be, though. [1] https://github.com/graninas/cpp_lenses https://github.com/graninas/cpp_lenses [2] https://github.com/jonsterling/Lens.hpp https://github.com/jonsterling/Lens.hpp