Xmonad中的StackSet

前几天论坛的一个网友告诉我有Xmonad这个东西，我就去查了一下。
Xmonad是一个Window Manager，它用于Unix的X11之上。这个WM是一种Tiling模式的WM。
Xmonad非常的轻量级，核心代码只有几百K而已，而且，它完全是用Haskell语言实现的。

它还有另外一个有意思的地方：它的配置文件是一个完整的Haskell文件，你可以在那里面写任意的haskell
代码，而每次启动的WM就是那个文件编译的结果。当然，真正的Xmonad的核心代码都是以库存在的，你的配置
文件中必须import这个库，而且，在main函数中要调用xmonad函数(如果不调用，那么执行完你的main之后，
程序就退出了)。

推崇这个窗口管理器的人认为，Tiling模式可以提高工作效率（因为你的双手不用离开键盘），在这种窗口
管理器中，鼠标完全是“可选的”，呵呵，事实上大部分图形界面的程序让你不得不用鼠标。

由于最近身体不好，就随便找些代码来看，仅供消遣。昨天晚上和今天晚上看了看xmonad-0.8/XMonad
/StackSet.hs文件。这个文件只有500多行，但却实现了窗口管理器用于管理窗口的容器数据结构。在些代码
中，最有意思的一个概念就是Zipper了，这个东西在wiki-book的Haskell/Zipper有详细的介绍。
Zipper本质上是一个可以"更新"，而且是纯粹的函数式的光标，用于指向一个数据结构
Zipper可以使我们替换一个在某个复杂数据结构(tree,term)深层的元素,而不需要改变很多。结果数据结构和
原来的版本会共享大部分子结构。

在这份代码中，作者对类型变量和参数起名字的方法及其诡异，我觉得这绝对应该改了。例如：
{code begin}
view :: (Eq s, Eq i) => i -> StackSet i l a s sd -> StackSet i l a s sd
view i s
    | i == currentTag s = s  -- i就是s的当前工作空间，返回s
...
{code end}
中，类型签名中的s（代表screen id的类型）和第二个参数s(代表StackSet类型的变量)几乎没有任何关系
。这种起名字的方式普遍存在。

另外，我认为differentiate函数和delete函数的算法复杂度错了，前者应该是O(1)的，后者在任何情况下
都是O(n)的。
函数delete'实现如下：
{code begin}
delete' :: (Eq a, Eq s) => a -> StackSet i l a s sd -> StackSet i l a s sd
delete' w s = s { current = removeFromScreen        (current s)
                , visible = map removeFromScreen    (visible s)
                , hidden  = map removeFromWorkspace (hidden  s) }
    where removeFromWorkspace ws = ws { stack = stack ws >>= filter (/=w) }
          removeFromScreen scr   = scr { workspace = removeFromWorkspace (workspace scr) }
{code end}
这个函数的实现也有问题。如果窗口允许重复，那么该函数没有任何问题。但是，从前面的注释可以知道，WM
管理的所有的工作区间上面的所有窗口都是唯一标号的，也就是不可能重复。那么，当删除一个窗口的时候
即便"current = removeFromScreen (current s)"已经把目标窗口删除了，该函数也必须执行后面的在
visible和hidden上面的map和filter操作。这个可能会造成效率的低下。理想的实现是，当删除一个窗口
后，就不再进行其他的查找工作了。

总之，Xmonad似乎是挺好玩的。我把它装上了，打算玩一阵子，烦了再换回GNOME