flatten exists in the stdlib with a different signature

I’m unsure of whether it’s intentional

one easy ticket

I've already provided the code and all, we just need tests in ApplicativeErrorLaws 😄

a couple of hacktoberfest tickets! https://github.com/arrow-kt/arrow/issues/1735 https://github.com/arrow-kt/arrow/issues/1732

Nit PR to fix some readmes https://github.com/arrow-kt/arrow/pull/1748

Created an issue that contains a description of the (root) problem and an idea how to fix it. Any opinions? https://github.com/arrow-kt/arrow/issues/1749

Hi guys, I'm glad to share a real thing with you, it is pretty new yet. These guys need our

arrow-rsocket

module, I think 😄 https://rsocket.io/

This is about reactive steams in the web (protocol over TCP or UPD, not sure). They do have

Java

and

Kotlin

implementation, but is is written in pretty declarative way and depends on implementation (there is

netty

strictly under the hood, for example). I thought FP paradigm can help this great protocol to improve.

Here is an intro talk by Oleh Dokuka,

rsocket

and

reactor

contributor:

Another case where a non-lazy applicative ap just straight up leads to bugs. I'd like some input on how to fix this because I am not sure what the right call is https://github.com/arrow-kt/arrow/issues/1755

Yes I am aware of this. I copied the Haskell implementation of some and many which are very elegant equations but unfortunately they require lazy evaluation as it is an infinite recursion.

I read that datatypes that have instances for Alternative override some and many implementations to be more specific and I ported them too fixing the problem for ListK, SequenceK and Option, but the default implementation is still failing and I'm trying to fix it because I need it for an applicative parsing mini exercise I'm trying to solve

Maybe some tinkering with Eval can solve the stackoverflow but I haven't been able to solve it yet, help is very appreciated 👐

@Miguel Coleto i don't think you can get a default stacksafe without having a lazy version of ap in applicative, and that would require eval in the argument of ap. But that would be one more method to implement for applicative so I don't know if it's a good idea

There are others like this like foldRight and require eval

We need to find better ergonomics for lazy stack safe that do not require a data type

We can probably solve this with compiler plugins allowing you to selectively inject a trampoline that is implicit when you want a call site to be stack safe

some short missing docs for

IO.cancelable

https://github.com/arrow-kt/arrow/pull/1788 https://github.com/arrow-kt/arrow/pull/1787

Is this possible in general, that

master

branch build is broken at some point of time?

quick PR to explain which Android versions can run Arrow https://github.com/arrow-kt/arrow/pull/1799

That is related too the non lazy folding of sequences because filterMap, which filter is defined with is map().foldLeft(). I'll add that too the ticket as well... We can solve those issues by explicitly overriding them, but tbh this isn't nice, sequences and the strict methods of our typeclasses don't play nicely when it comes to default implementations. Don't really know what the best thing is here, probably just going the long route and explicitly defining everything for sequences is best

If it helps in any way in my upcoming meta work for kinds and type proofs, kinds no longer require inheritance so you don’t need ListK, SequenceK or any wrapper