I plan on automating a bunch of those annoying things that we need to keep maintaining like listing stuff from datatypes and type classes.

This will give auto doc to all data types as they are fresh and not yet have the usual lyrics atop the page

I mean, annotation processors are super useful but they slow down compilation time a lot, and we totally rely on them. If there's any chance to enhance that it'd be required IMHO

awesome let us know when you want a closer look, so far looks very interesting.

Documentation for Traverse: https://github.com/arrow-kt/arrow/pull/1127

I'm integrating Dokka with Ank and the Try Arrow playgrounds so in the next release we can have access to the entire suite of API docs directly on the site and we can play with the examples driven by the code. The code is also compiled by ank to ensure kdoc snippets don't fall behind as source evolve. This:

Will give you playgrounds support in the generated dokka docs precompiled by ank. It's all also integrated in the current site, just need to tweak some styles.

Can we get rid of

{: data-executable='true'}

?

Could I do a snippet without main and still get it inlined and checked by ank?

Awesome work on docs btw 👏

Can we get rid of

{: data-executable='true'}

?

Once I add

ank:playground

which inserts that automatically

Could I do a snippet without main and still get it inlined and checked by ank?

Yes, that already works and you get the result printed in the same way as we do in the regular docs.

I'm also considering generating the main boilerplate with ank so the declaration of the example is the same as with the rest of ank. Last line gets printed.

The arrow dokka gradle tasks generates over 13K markdown files and makes jekyll take about 10 mins to start up

jekyll serve

😮

Any idea what they're doing?

It generates one page per function in addition to all the types and package ones

Jekyll has to parse them to turn the markdown into html

It works at the end but it's slow

Ah right all the functions have separate pages.

Ready for review

Looks great @simon.vergauwen

Hi, folks. Shouldn't we have a

lift

for the Bifunctor class? I noticed that it doesn't have it. It could be just like this:

interface Bifunctor<F> {
    fun <A, B, C, D> Kind2<F, A, B>.bimap(fl: (A) -> C, fr: (B) -> D): Kind2<F, C, D>

    fun <A, B, C, D> lift(fl: (A) -> C, fr: (B) -> D): (Kind2<F, A, B>) -> Kind2<F, C, D> = { kind2 ->
        kind2.bimap(fl, fr)
    }
// more code...

If it makes sense, I'll open a PR

yep, go for it! Also, is it

bilift

? check with haskell/scala

Ok

So Cats doesn't have lift for Bifunctor '-' . I don't know Haskell enough to know if it has lift for Bifuntors in the language. I still think that it makes sense, although this is really bugging my. What do you think?