使用镜头有哪些优缺点？

Question

镜头似乎没有任何缺点,同时具有优于标准Haskell的显着优势:是否有任何理由我不应该尽可能使用镜头？有性能考虑吗？另外,模板Haskell是否有任何重大开销？

Answer 1

镜像形成了对数据构造函数使用直接闭包的替代方法.因此,镜头与直接使用函数和数据构造函数具有大致相同的警告.

一些缺点是因为:

• 每次修改镜头时,都可能会导致(重新)创建大量对象.例如,如果您有此数据结构:

  A { B { C { bla = "foo" } } }
  

  ...和类型的镜头Lens A String,您将创建一个新的A,B并且C每次"修改"那个镜头.这在Haskell(创建大量对象)中并不罕见,但是对象创建隐藏在镜头后面,因此很难将其视为潜在的性能下沉.

• 由于使用了"映射功能",镜头也可能产生低效率.例如,如果您制作的镜头修改了列表中的^第 26 ^个元素,则可能会因查找时间而导致大量减速.

和专业人士:

• 镜头与常规记录相结合,可以与状态monad一起使用(参见data-lens-fd示例),这样可以避免由于大量数据共享而在大多数时间内重新创建大量对象.请参阅示例focus函数,以及withSomething在Snap Web框架中使用函数的类似模式.
• 镜头显然实际上并没有就地修改任何内存,所以当你需要在并发环境中推理状态时它们非常有用.因此,在处理各种图形时,镜头非常有用.

但是,镜头并不总是与数据构造函数的闭包同构.以下是一些差异(data-lens作为此处的实现):

• 大多数镜头实现使用某种形式的数据类型来将"存取器"和"增变器"存储为一对.因为data-lens,这是Storecomonad.这意味着每次创建镜头时,由于创建了数据结构,所以会产生非常小的额外开销.
• 因为镜头通过某些未知的映射依赖于值,所以可能更难以推理垃圾收集,并且您可能会因为忘记使用依赖于大块内存的非常通用镜头而导致(逻辑)内存泄漏.例如,一个镜头可以访问某个大型矢量中的元素,该矢量由另一个隐藏第一个镜头的镜头组成,这使得很难看出合成镜头仍然依赖于大量的存储器.

模板Haskell代码在编译时运行,并且不会影响镜头的运行时性能.

Answer 2

我假设数据镜头包.对于类似数据的事物(记录,元组,地图等),镜头对我来说表现非常好.实际上,它们有时甚至比正常方法表现更好,可能是因为更好的共享.在性能方面,它产生的性能与您手工编写的代码大致相同.

然而,有类似功能的东西,镜头可能会受到惩罚.例如,我至少记得一次使用像这样的镜头:

result :: (Eq a) => a -> Lens (a -> b) b

虽然查询非常快,但我偶尔会覆盖函数的某些结果值以将其调整为特定的场景,这相当于将函数的主体包含在一个大的中if.当然,性能影响与镜头本身无关,但值得注意.