Discussion: reconsider lens-like exports from containers

[Edward Kmett]

Good catch. We might see if Coyoneda works better than Yoneda for
`fusing` in lens in practice as well.

-Edward

On Thu, Apr 28, 2016 at 2:48 PM, David Feuer <david.feuer at gmail.com> wrote:
> AHA! I was wrong! There *is* (some) hope! I should've realized this
> earlier. The trick is to use Coyoneda instead of Yoneda. Coyoneda is
> effectively lazier than Yoneda, so nodes can become available as soon
> as they're passed. I suspect it may also be helpful that while
> liftYoneda is pricier than lowerYoneda for non-trivial functors, the
> opposite holds for Coyoneda. Since adjustA does a lot more lifting
> than lowering, Coyoneda seems like a better fit. A thoroughly
> straightforward Coyoneda-based implementation offers *decent*
> (although not wonderful) viewing performance. But as soon as it's
> passed something that reads *and* modifies, it does a little better
> than the fake version.
>
> On Wed, Apr 27, 2016 at 10:15 PM, David Feuer <david.feuer at gmail.com> wrote:
>> 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