5 ms·

These are what I think the author is looking for. But it shouldn't be a "primitive" in terms of code automatically generated by the compiler, but an interface o

These are what I think the author is looking for. But it shouldn't be a "primitive" in terms of code automatically generated by the compiler, but an interface or typeclass like your examples (in a language advanced enough to have them.) The problem is that 'lens', 'monocle', etc. are famously abstract and difficult for people to apply to their actual problems. IMO, the solution would be for standard libraries to specify interfaces called 'BreadthFirstTraverse', 'DepthFirstTraverse', etc.

naasking 1y ago
> These are what I think the author is looking for. But it shouldn't be a "primitive" in terms of code automatically generated by the compiler I think people are often too enamored by general purpose languages that can express such abstractions natively. I don't see an issue with a language that provides this as a primitive without being able to express it itself, constraints can be useful for other properties. Once you can traverse trees, most programming problems can be tackled even in such constrained languages, eg. SQL with CTE.
eru 1y ago
Haskell has 'Traversable' (and 'Foldable' etc) which are a lot more approachable than the fully generalised lens library.
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

naasking 1y ago

> These are what I think the author is looking for. But it shouldn't be a "primitive" in terms of code automatically generated by the compiler I think people are often too enamored by general purpose languages that can express such abstractions natively. I don't see an issue with a language that provides this as a primitive without being able to express it itself, constraints can be useful for other properties. Once you can traverse trees, most programming problems can be tackled even in such constrained languages, eg. SQL with CTE.

eru 1y ago

Haskell has 'Traversable' (and 'Foldable' etc) which are a lot more approachable than the fully generalised lens library.

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