6 patches for repository http://darcs.net/screened:

patch 733e1eb0c2cc1080f059d0ea2ee3eac9095bbe42
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri Jul 17 19:37:33 CEST 2020
  * cleanup D.U.Tree.Monad: remove classes TreeRO and TreeRW
  
  This merely turns the former methods into plain overloaded functions.

patch c511efd78e6b46e3249736443a669df4e9f11514
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri Jul 17 19:48:40 CEST 2020
  * general cleanup of D.U.Tree.Monad
  
  This makes a small API change: initialState is no longer exported, instead
  runTreeMonad gets passed the ingredients directly. The main internal change
  is that the updateHash and update procedures have been moved from the
  TreeState to the reader part of the monad, for which there is now a new data
  type TreeEnv. Otherwise this cleans up and documents the export list and
  many of the haddocks, and moves things around a bit.

patch 2b28f5712d5e0bc3c4a5b6a6f85e2c471e8bae15
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Dec 21 13:49:19 CET 2020
  * simplify TreeMonad by removing its "current working directory" emulation
  
  Darcs suffers enough from cwd issues in the IO monad. Adding to that by
  emulating a "current working directory" as ambient state in the TreeMonad
  was a bad idea from the start. Fortunately the only place where this
  misfeature was used is in the implementation of treeHasAnycase. The new
  implementation of that procedure is both safer and easier to understand.

patch 02cbe6ed53838806a38a5e454f8b038cf14a7a2d
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Dec 21 14:24:31 CET 2020
  * further simplify Darcs.UI.Commands.Util.Tree
  
  Use of the TreeMonad here is overkill and can be avoided by adding a simple
  monadic variant of Darcs.Util.Tree.find expands Stubs on the way. Also
  export isSub from Darcs.Util.Tree for convenience.

patch 99a8a1a27bee59fbb365e6b80060582483f9383b
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Dec 21 14:31:13 CET 2020
  * rename Darcs.Util.Tree.isSub to isDir

patch 9771ab5c87b2fa590084cfae57adc9259362e9fb
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Dec 21 14:51:10 CET 2020
  * move stuff from Darcs.UI.Commands.Util.Tree to Darcs.Util.Tree

Attachments

• cleanup-d_u_tree_monad_-remove-classes-treero-and-treerw.dpatch
• patch-preview.txt
• unnamed

>   * cleanup D.U.Tree.Monad: remove classes TreeRO and TreeRW

OK

>   * general cleanup of D.U.Tree.Monad

OK

>   * simplify TreeMonad by removing its "current working directory" emulation

OK, definitely a nice simplification

>   * further simplify Darcs.UI.Commands.Util.Tree

>   Use of the TreeMonad here is overkill and can be avoided by adding a simple
>   monadic variant of Darcs.Util.Tree.find expands Stubs on the way. Also
>   export isSub from Darcs.Util.Tree for convenience.

OK, though it's not obvious to me that adding new code is an improvement
unless the end goal is to get rid of TM.exists etc.

>   * rename Darcs.Util.Tree.isSub to isDir
>   * move stuff from Darcs.UI.Commands.Util.Tree to Darcs.Util.Tree

OK

>>   * further simplify Darcs.UI.Commands.Util.Tree
> 
>>   Use of the TreeMonad here is overkill and can be avoided by adding a simple
>>   monadic variant of Darcs.Util.Tree.find expands Stubs on the way. Also
>>   export isSub from Darcs.Util.Tree for convenience.
> 
> OK, though it's not obvious to me that adding new code is an improvement
> unless the end goal is to get rid of TM.exists etc.

The goal was to get rid of Darcs.UI.Commands.Util.Tree as realized in

* move stuff from Darcs.UI.Commands.Util.Tree to Darcs.Util.Tree

The exist* functions in TreeMonad are needed elsewhere e.g. in the
instance ApplyMonad.

In general, an imperative IO-like API such as TreeMonad should (IMHO) be
avoided when better alternatives, such as directly operating on Trees in
a functional style, are suitable. The only excuse for TreeMonad is that
it provides us with an efficient ApplyMonad instance. In particular, the
TreeMonad mechanism allows us to apply long chains of patches in
constant memory. (Although, now that I think about it, shouldn't it be
possible to achieve the same with a pure apply?)