Can we add some version of <<++~, <<+~, etc. that can see the old version without too much confusion? about lens HOT 8 CLOSED

As for <<, the main problem I have there is that I've been seriously considering adding a number of combinators for using applicative modification.

<*>~, etc. This means that you'd have <<*~ with a different semantics being consistently used.

The main reason I haven't actually done this already is that of course, you'd want *>~ and this means that there are two contenders for <*>~. ;)

from lens.

@orenbenkiki had a fair bit to say in a further reply on #36.

from lens.

More traffic over on #36.

from lens.

Moving the < to the far right hand side of the operator (past the ~ or =) might lead to consistent semiotics that doesn't collide.

fresh = id +=< 1

But the result is a pretty ugly operator.

from lens.

We could just supply a single <<%~ operator.

Then the user could use _2 <<%~ (+1) and we could avoid any confusion with other operators that start with <.

from lens.

This would certainly be less intrusive than going over each and every <op~ and <op= operator (there is quite a list of these). It seems like a reasonable compromise...

from lens.

There are 4 commented-out test cases in hunit.hs demonstrating these operators that need to be re-enabled. You may use the opportunity to eliminate the comment about the uncovered use cases, given it is "decided" not to do the monadic modification operators.

from lens.

Good catch. Re-enabling

from lens.