You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It’s quite easy to produce a lens with, for example, lens-join/list that is not actually a lens; that is, it does not respect the lens laws. Specifically, the produced lens violates set-get consistency when the views of the sublenses overlap. Here’s an example:
> (let ([l (lens-join/list first-lens first-lens)])
(lens-view l (lens-set l '(a b) '(12))))
'(22)
This produces '(2 2), but the set-get consistency law demands that it produce '(1 2).
The documentation sort of notes this in the following comment:
If any of the lenses share views, then when setting the later lenses override the earlier ones.
However, I don’t think this is phrased quite scarily enough. I think it should be reworded to make it quite clear that the lens-join/* functions do not produce legal lenses when given lenses with overlapping views.
The text was updated successfully, but these errors were encountered:
It’s quite easy to produce a lens with, for example,
lens-join/list
that is not actually a lens; that is, it does not respect the lens laws. Specifically, the produced lens violates set-get consistency when the views of the sublenses overlap. Here’s an example:This produces
'(2 2)
, but the set-get consistency law demands that it produce'(1 2)
.The documentation sort of notes this in the following comment:
However, I don’t think this is phrased quite scarily enough. I think it should be reworded to make it quite clear that the
lens-join/*
functions do not produce legal lenses when given lenses with overlapping views.The text was updated successfully, but these errors were encountered: