Discussion: reconsider lens-like exports from containers

[David Feuer]

Using Yoneda greatly improved performance for Identity, and raised the
performance for [] a little above that of the "fake" version lens
currently uses. But the performance for simply viewing an element is
awful (it takes about twice as long as `index`), and I'm beginning to
doubt there's any solution that will get the (small) speed-up in some
cases without getting a (large) slow-down elsewhere. Oh well.

On Wed, Apr 27, 2016 at 6:39 PM, Edward Kmett <ekmett at gmail.com> wrote:
> That transformation is effectively what 'fusing' does. It CPSes (er..
> Yonedas, actually) the functor `f` as forall r. (a -> r) -> f r, and
> accumulates the changes by composing in more functions, so that it can
> all be discharged with one fmap. You should be able to achieve the
> same result by hand with a manual worker/wrapper transformation.
>
> -Edward
>
> On Thu, Apr 28, 2016 at 8:20 AM, David Feuer <david.feuer at gmail.com> wrote:
>> I was thinking switching to CPS might help, passing the context down on the
>> way to the leaf, so the tree is built "inside" the functor. This is pretty
>> easy for nodes and digits, but I'm struggling with the polymorphic recursion
>> in the spine right now. I think I'll probably figure it out eventually.
>>
>> On Apr 27, 2016 6:12 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>>>
>>> For cases were the Functor winds up particularly complicated or won't
>>> be known at compile time so the inlining can't help, it turns out you
>>> can usually work around this with the 'fusing' combinator from the
>>> lens library. This works around the repeated stacks of `fmap` that get
>>> built up otherwise, transforming everything into one gigantic fmap all
>>> in one go.
>>>
>>> There is a similar `confusing` combinator for working with traversals.
>>> The implementation lives up to the name.
>>>
>>> -Edward
>>>
>>> On Wed, Apr 27, 2016 at 5:19 PM,  <rf at rufflewind.com> wrote:
>>> > On Tue, Apr 26, 2016, at 15:03, David Feuer wrote:
>>> >> Way back when, Shachaf Ben-Kiki suggested an efficient implementation
>>> >> of `at` for Data.Map in
>>> >> https://mail.haskell.org/pipermail/libraries/2013-May/019761.html but
>>> >> that was never approved for inclusion.
>>> >
>>> > Funny thing, I just tried doing that not to long ago with `at`:
>>> >
>>> > https://github.com/haskell/containers/pull/192
>>> >
>>> > In the end, the results were mixed.  It was a small optimization in some
>>> > situations, and a moderate pessimization in others (esp. when the
>>> > Functor becomes too complex for GHC to optimize).
>>> >
>>> > --
>>> > RF
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries