并不只是 mv images/* . ; rm images ; 那么简单。别忘了还有当名字冲突时的replacement操作（通常我们希望保留 最新修改的文件 或 体积较大的文件）。
举个例子： 一个Set Monad ((a,b,c) (b,c,d))，对它flattern后要变成 (a,b,c,d)。
真相了。lens还是挺好用的，不过lens跟题主说的好像没关系
-
我不明白一个简单的 Tree 结构为何非要上升到 Monad 上，感觉就像是我在搬砖非要说成长方体空间位移操作师一样。压平树 / 合并子树这种操作是个脚本都能写吧，不在函数声明里面写个
Monad m =>也不见得就浑身难受。 -
资源管理器的搜索不是单纯的 filter 哦，它等效于压平后再过滤吧。如果过滤条件为任意条件，相当于压平。
-
我赞成 lz 给所有能 Monad 的东西都加个 GUI 壳，说不定是未来 HCI 的重要方向。
6 个赞
Zipper 怎么用在 flatten 上呢？
只是觉得操作文件系统这种树状结构还是zipper比较舒服，比如切换目录之类的，flatten大概就是子树拿出来遍历一下再插回去吧
然后文件系统的树当成个Traversable，再来个FileSet之类的Monoid最后sequenceA一下？
是可以用脚本，但是一些常用的功能有GUI壳更好。比如：搜索功能，windows专门提供了一个搜索栏，但它也可以选择不提供，让用户写脚本去搜索。
flatten只压扁一层，而搜索*会把整个目录树全压扁。
突然想起来一个问题：如果你限定文件夹下面要不都是子文件夹，要不就是文件。那么 flatten 是不是就类似于 append？当然需要调整一下（不过一想，即使没有限制，拍扁一棵树本来就很简单
拷贝/剪切+粘贴才是append，flatten不是。
flatten除了要把文件夹里面的文件剪切出来拷到外面，还要把该文件夹本身删除。
除非取消文件夹，否则 tag 始终鸡肋一般的存在。
使用标签，需要文件本身（例如 mp3，电影等等）携带足够的信息，不然样样都手工 tag 就太累了。
2 个赞