Non applicable #14 #30
Conversation
|
Even if lenses aren't two-value functions any more, it still makes sense to keep the |
|
Computation-sharing can be supported in a separate issue (I'll make one to track it). It's not always better to share computation - all cases where only getting or setting is needed take on the penalty of computing what's needed for the other half. However, by not exposing the struct at all and only exposing make-lens, apply-lens, and let-lens, at a later date an alternate representation that stores a function that computes both at once can be used, and a version of make-lens that takes such a sharing function could be added. I'd also really like some data on performance-intensive uses of lenses and where the bottlenecks arise. |
|
Well, isn't it simpler to keep the representation the way it is now, and possibly add your new one later? Plus, the getter will not have to compute any setter-specific information unless you define it that way, but the setter can take advantage of computations already done by the getter. |
|
The representation isn't really the problem, the problem is that all other lens-defining modules are explicitly depending on that exact representation. That locks me out of ever being able to change that representation. I imagine for some lenses the separate getter and setters would be more performant than sharing. For now I want all lenses to only be defined in terms of make-lens. I've also found it makes the implementation of most lenses clearer and is a nicer API to use. Bottom line, I want to get rid of implementation-dependent constructions of lenses until I figure out how to properly support computation-sharing lenses. |
|
If they use make-lens, which is already define in terms of the lens-struct and the 2-value function, then they aren't depending on that representation, and it shouldn't slow down the getter very much. However, if you want to make the setter more efficient by re-using computations already done by the getter, then the previous representation is the best one. |
|
Agreed, and I plan to support that, but in a way better than the previous representation. There's much to do in the realm of optimization, and I'm hesitant to devote much time or complexity to it before committing to a 1.0 API |
|
Well, changing it back isn't adding any complexity, really: #33 |
|
As I said, I don't want to do it yet until I have more information about the relative costs of computation sharing and what other optimizations are possible. For instance, with separated lenses lens-compose can be optimized to compose the underlying getters and setters independently. The performance implications and possible optimizations are not straightforward, neither is directly more flexible and efficient than the other in all circumstances. For that reason, I'm sticking with separated lenses to keep the implementation simple for 1.0, then looking into optimization later. |
|
A possible solution: Would it be a good idea to make this into a That way the interface stays the same, but different implementations can take different trade-offs, and functions like |
|
Yes, that's a good idea, and wouldn't break backwards compatibility. I'm primarily concerned with getting the 1.0 api documented and solidified first however, so that will have to be a post-1.0 addition. |
|
Ok, but would |
|
Yes, |
If you don't want lens modules to depend on the representation, and especially if you want to avoid being locked out of being able to change it, then it seems like a generic interface is exactly what you want. That's what gave me the idea. |
|
It is, with the exception that if I actually expose and document the generic interface I'm locked into the fact that it must be generic as well, as clients of the package could make arbitrary representations of lenses. I am yet not sure if that extensibility is a good idea. All I know 100% for certain at this point is that I want to be able to pass a getter and setter to |
|
Would it work if we only exposed it in the unstable collection? |
No description provided.