关于“当前主流操作系统的文件管理器是否缺少Monad操作”的一点思考

并不只是 mv images/* . ; rm images ; 那么简单。别忘了还有当名字冲突时的replacement操作(通常我们希望保留 最新修改的文件 或 体积较大的文件)。

举个例子: 一个Set Monad ((a,b,c) (b,c,d)),对它flattern后要变成 (a,b,c,d)。

真相了。lens还是挺好用的,不过lens跟题主说的好像没关系

  1. 我不明白一个简单的 Tree 结构为何非要上升到 Monad 上,感觉就像是我在搬砖非要说成长方体空间位移操作师一样。压平树 / 合并子树这种操作是个脚本都能写吧,不在函数声明里面写个 Monad m => 也不见得就浑身难受。

  2. 资源管理器的搜索不是单纯的 filter 哦,它等效于压平后再过滤吧。如果过滤条件为任意条件,相当于压平。

  3. 我赞成 lz 给所有能 Monad 的东西都加个 GUI 壳,说不定是未来 HCI 的重要方向。

6 个赞

https://wiki.haskell.org/Zipper

2 个赞

Zipper 怎么用在 flatten 上呢?

只是觉得操作文件系统这种树状结构还是zipper比较舒服,比如切换目录之类的,flatten大概就是子树拿出来遍历一下再插回去吧

然后文件系统的树当成个Traversable,再来个FileSet之类的Monoid最后sequenceA一下?

是可以用脚本,但是一些常用的功能有GUI壳更好。比如:搜索功能,windows专门提供了一个搜索栏,但它也可以选择不提供,让用户写脚本去搜索。

flatten只压扁一层,而搜索*会把整个目录树全压扁。

突然想起来一个问题:如果你限定文件夹下面要不都是子文件夹,要不就是文件。那么 flatten 是不是就类似于 append?当然需要调整一下(不过一想,即使没有限制,拍扁一棵树本来就很简单

拷贝/剪切+粘贴才是append,flatten不是。

flatten除了要把文件夹里面的文件剪切出来拷到外面,还要把该文件夹本身删除。

除非取消文件夹,否则 tag 始终鸡肋一般的存在。

使用标签,需要文件本身(例如 mp3,电影等等)携带足够的信息,不然样样都手工 tag 就太累了。

2 个赞