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

[ekmett]

Oren's wishlist included functions that can post-increment/multiply/append rather than pre-increment/multiply/append, showing us the old version rather than the new.

What semiotics would make sense for these operations? And can they be supported without adding undue complexity to the already baroque set of operators?

This was originally raised by @orenbenkiki in #36.

[ekmett]

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 <*>~. ;)

[ekmett]

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

[ekmett]

More traffic over on #36.

[ekmett]

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.

[ekmett]

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 <.

[orenbenkiki]

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...

[orenbenkiki]

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.

[ekmett]

Good catch. Re-enabling