Open davidgarland opened 1 year ago
These comments might be outdated and/or wrong.
I don't think we have any inspection tests that check how a combination of vl/profunctor lenses optimize, it would be nice to add some (and update the documentation if necessary).
Just to clarify, I wrote the first comment and the bit Do not define lens in terms of lensVL
refers to the lens
function that's being defined, not lenses in general, it should be still relevant.
As for the second claim, I think it refers to converting between the VL and profunctor encoding with lensVL
/toLensVL
? But I'm not sure, I don't remember writing it. @adamgundry did you do it?
It's somewhat vague and might be unsubstantiated, inspection tests would be good to check.
I notice this comment in the implementation of the
lens
function:Reading this, in addition to reading the warning on the van Laarhoven encoding section saying
makes me think that I ought to outright avoid use of
lensVL
in my code.What confuses me, though, is that I see in Optics.TH's documentation all of the generated lenses use
lensVL
, and using-ddump-splices
confirms this is indeed what's generated.My questions are:
lensVL
in Optics.TH?lensVL
definitions with custom ones that were defined usinglens
?lensVL
instead? (If so, why do the docs seem to implicitly discourage use oflensVL
?)(I don't consider this a massive flaw in the documentation, though some clarification on this being added might be nice-- if this repo had a "Discussion" tab added I would've asked this there instead.)