8

我很欣赏 Control.Lens 包。它确实有助于稍微弱一点的 Haskell 记录语法。我正在研究库的某些部分，其中性能是一个问题。有谁知道与函数中的基本模式匹配相比，使用通过如下所示的类型类公开的简单镜头会产生什么性能损失（如果有的话）？像这样使用 Lenses 有可能很好地解决记录命名空间冲突问题。我可以自己设置一些基准，但很好奇是否有人可以为我省去麻烦。谢谢。

镜头类

class LensX v where
  _x :: Functor f => (Double -> f Double) -> v -> f v

class LensY v where
  _y :: Functor f => (Double -> f Double) -> v -> f v

class LensZ v where
  _z :: Functor f => (Double -> f Double) -> v -> f v

镜头实例

instance LensX Vec3 where
  _x f (Vec3 x y z) = fmap (\x' -> Vec3 x' y z) (f x)

instance LensY Vec3 where
  _y f (Vec3 x y z) = fmap (\y' -> Vec3 x y' z) (f y)

instance LensZ Vec3 where
  _z f (Vec3 x y z) = fmap (\z' -> Vec3 x y z') (f z)

提供 Lenses 的模块不必导入 Control.Lens 包，非常棒。此页面https://github.com/ekmett/lens/描述了该库的使用。

4

1 回答 1

8

您为这种类型的镜头支付了少量的性能损失。它来自所有具有导致字典传递发生的约束的更高级别的类型。

这是您想回到data-lens的罕见情况之一，它没有这个问题，甚至可以使您的代码更快。Data-lens，如果你解码Storecomonad间接，使用你可以对一个镜头最直接的表示：

newtype Lens s a = Lens (s -> (a, a -> s))

虽然该库本身不支持多态镜头，但您可以构建自己的镜头类型，并且仍然可以为您提供高性能：

newtype Lens s t a b = Lens (s -> (a, b -> t))

对于您的特定目的，您可能还对线性包感兴趣。

于 2013-02-13T07:58:43.443 回答