4 ms·

In C you don't need lens, either you set a member of a struct or you copy the struct and you set a member of the copy, trivial stuff. Why do you need a library

• oever 8y ago
  In Haskell, structures are immutable. You cannot set a member on a copy, because the copy is immutable too. You have to provide the new value to the constructor. The lenses are syntactic sugar to create a copy with only one member changed. It's not pretty nor efficient, but a result of having only immutable structures.
  • zoul 8y ago
    You make it sound like lenses are a sort of a crutch, but in my opionion they are not. The idea of having a first-class, composable way to “focus” on a part of a larger structure makes a lot of sense. And can be very pretty, too – see Swift’s key paths. That kind of type safety and simplicity is very appealing to me. As for efficiency, copying stuff usually means improved thread safety, so that’s win for me. Also, copy on write makes things often much more efficient in practice.
• marcosdumay 8y ago
  Is there a common idiom in C++ to deep copy a multi-level structure so you can then change a field? In C I know there isn't, and you can not create a generic function for it either. How do you pass a member identification as a parameter to a function that may receive any kind of structure, and then update that member? Haskell has record accessors too, that are more equivalent to the C functionality. Lenses are a different thing.
  • atilaneves 8y ago
    > How do you pass a member identification as a parameter to a function that may receive any kind of structure, and then update that member? You don't. You just update that member.
    • marcosdumay 8y ago
      So, no generics available (templates are an option, but way to troublesome to use for that). That aligns with my experience, but mine is currently out of date, thus the question.
      • atilaneves 8y ago
        The main takeaway is that this isn't necessary with mutable structures. Nobody would think of even trying to write a generic solution to a problem that doesn't exist in C++.
        • marcosdumay 8y ago
          Lens are about composition and abstracting your operations over unknown structures. I don't know where did you find anything about immutability, as plain data accessors are perfectly fine for that. The motivation on the article is basically this paragraph: "Lenses allow you to abstract state shape behind getters and setters. Instead of littering your codebase with code that dives deep into the shape of a particular object, import a lens. If you later need to change the state shape, you can do so in the lens, and none of the code that depends on the lens will need to change." Immutability does not make its way there.
  • munchbunny 8y ago
    You are trying to apply concepts where the paradigm your are operating in (C or C++'s) doesn't solve the problem the same way. In C++, you forward responsibility for knowing object shape down the line of composition. You also generally avoid deep copies because they are expensive. This leads to using getter/setter methods to abstract object shape at module boundaries. If you're dealing with immutable objects, then you bake that into the interface (such as std::string). If you were deep copying objects in C++, first I would ask whether you really need to. If you really did, then the idiomatic way is to either provide a function like ".clone" or to implement the copy constructor to do it. How do you pass a member identification as a parameter to a function that may receive any kind of structure, and then update that member? You don't, because that's not something C++ as a language can do. So instead, the question is how you got into a situation in C++ where you need to. On the point about composability, in C++ the composition happens at the object level. You don't compose getting/setting functions because that's not how C++ addresses the same problem.