我一直在撞墙一段时间。我有一堆类型,它们代表基本类型的转换(更具体地说,是XMonad中的布局修饰符)。
长话短说,这些类型都有点(* -> *) -> * -> *
。
我想做的事情,由于我不想在这里讨论的原因,是采取一堆这些转换,并将它们表示为基类型(类型* -> *
)的单一转换。 / p>
我的第一个想法是定义一个类型合成运算符
newtype ((f :: (* -> *) -> * -> *) :. (g :: (* -> *) -> * -> *)) l a
= Compose (f (g l) a)
它在大多数情况下都有效。但是,给定一个值,比如说v :: f1 (f2 (f3 (... (fn l))) a
,我必须将Compose
n-1
次应用到它来获取v' :: (f1 :. f2 :. ... :. fn) l a
,这不是很漂亮而且有点讨厌。
所以,问题是,有没有办法自动应用Compose
,直到我得到我想要的东西?
F.ex。,现在我这样做:
modifyLayout $ Compose . Compose . Compose . Mirror . avoidStruts . minimize . smartBorders
我想做什么:
modifyLayout' $ Mirror . avoidStruts . minimize . smartBorders
where modifyLayout' = modifyLayout . magicCompose
一个相关的问题:也许有更好的方式来表达相同的概念?
作为参考,modifyLayout
是
modifyLayout :: (CC m Window)
=> (forall l. (LayoutClass l Window) => l Window -> m l Window)
-> ConfigMonad
澄清(编辑):
使用类型组合背后的整个想法是这样的。
考虑两个布局修饰符
m1 :: LayoutClass l a => l a -> M1 l a
和
m2 :: LayoutClass l a => l a -> M2 l a
如果我写这两个,我得
m1m2 :: (LayoutClass l a, LayoutClass (M2 l) a) => l a -> M1 (M2 l) a
m1m2 = m1 . m2
我们可以假设有一个instance LayoutClass l a => LayoutClass (M2 l) a
。在此期间,还假设有CC M1 Window
和CC M2 Window
的实例。
如果我现在尝试将其提供给上面定义的modifyLayout
:
modifyLayout m1m2
GHC立即对嵌套类型和抱怨感到困惑:
Couldn't match type ‘l’ with ‘M2 l’
‘l’ is a rigid type variable bound by
a type expected by the context:
LayoutClass l Window => l Window -> M1 l Window
Expected type: l Window -> M1 l Window
Actual type: l Window -> M1 (M2 l) Window
使用类型组合,我可以纠正这一点,因为GHC在M1 :. M2
签名中匹配m
modifyLayout
,并避免整个嵌套混淆。类型同义词显然不具备此属性。
更新
经过一番探索后,我发现了一个局部解决方案(不知道为什么我没有早点想到它,但是很好)
可以定义像这样的类型类
class S l f t | f l -> t where
sq :: (l a -> f a) -> (l a -> t l a)
功能依赖性确保编译器能够自己选择实例。
然后,可以编写像这样的实例
instance S l (m1 l) m1 where
sq = id
instance S l (m1 (m2 l)) (m1 :. m2) where
sq = sq . (Compose .)
instance S l (m1 (m2 (x l))) ((m1 :. m2) :. x) where
sq = sq . (Compose .)
instance S l (m1 (m2 (m3 (x l)))) (((m1 :. m2) :. m3) :. x) where
sq = sq . (Compose .)
-- etc
这部分回答了我的问题:sq
封装了一个转换堆栈,前提是为给定的嵌套级别定义了一个实例。
但是,这些实例似乎要求递归实例定义。到目前为止,我还是无法弄清楚它究竟会是什么样子。所以,欢迎任何见解。
答案 0 :(得分:2)
感谢Adam Vogt(@aavogt),我终于得出了令人满意的结论。
我在S
班级的实例上走在正确的轨道上。事实证明,逆转实例依赖性允许typechecker推断其他实例。但是,递归终止(即基本情况)需要IncoherentInstances
扩展。
以下是代码:
instance {-# INCOHERENT #-} S l (m l) m where
sq = id
instance S l ((f :. g) l') t => S l (f (g l')) t where
sq = squash . (Compose .)