Backport Bifunctorial IO

[emilypi]

This PR ports the new BiFunctor IO version referenced here, including the minimal subset of things necessary to make it work, such as @alexknvl's better Void implementation merged a week ago.

[fosskers]

I will bench this sexy shit.

[fosskers]

No regressions between this an IO[A], as far as I can tell.

[emilypi]

@fommil do you care to take a look? @fosskers' benchmarks show no regressions, all tests pass etc. We can debate licensing over on the other PR and merge it in as a separate PR

[fommil]

@jdegoes are you ok with bsd3 on this or maybe use it as an lgpl pilot?

[jdegoes]

@fommil I'm good with an LGPL pilot! 👍

[tonymorris]

Scalaz needs to remain BSD3.

On Thu., 19 Apr. 2018, 12:42 John A. De Goes, notifications@github.com wrote:

@jdegoes commented on this pull request.

In src/main/scala/scalaz/ioeffect/IORef.scala https://github.com/scalaz/ioeffect/pull/18#discussion_r182620999:

*/

• final def modify(f: A => A): IO[A] = IO.sync {
• val cur = value.get()
• val next = f(cur)
• value.set(next)
• final def tryWrite[E](a: A): IO[E, Boolean] =

Well, you can use tryWrite in a loop to build your own modify that takes different actions under contention. That said, I think you've made a good case for a low-level CAS. I'll add one!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/scalaz/ioeffect/pull/18#discussion_r182620999, or mute the thread https://github.com/notifications/unsubscribe-auth/AAM2fipgBO5P88ve7Gcue8stwaEqu2mhks5tp_mYgaJpZM4TXmr3 .

[tonymorris]

Here are two messages that I received on 2018-04-18 (yesterday for me) regarding scalaz licence.

GPL i'd be pretty much 'well there goes the last time i ever look at the code'

LGPL i'm decidedly meh about

[jedws]

great stuff @emilypi (and @jdegoes )

[fommil]

@tonymorris for scalaz8, I'll use whatever the other contributors decide upon. I'm unlikely to be a scalaz8 contributor as I plan on moving my attention to Haskell: so I don't think my voice should carry any weight on that discussion. It's clear that 7.2 and 7.3 are not changing their license and I've changed my own LGPL in scalaz-deriving-base to BSD3 because I think it makes sense in core.

In this case, which is backported scalaz8 code, it's 100% up to @jdegoes, and this is an independent module (not scalaz). Whatever license he wants to use is what we get and I only see an LGPLv3 (which I am delighted about, btw). This PR should be changed to LGPL unless John gives the thumbs up on the (current) BSD3. We can't take somebody's LGPL code and then paste it into a BSD3 project, they need to agree to it.

[fommil]

my last comment was a bit waffly. The TL;DR is: @jdegoes are you ok with the current BSD3 license of this repository or do you want to think about it for a bit?

[emilypi]

For the record (and whatever it's worth), I agree with @tonymorris on this one. I see no sense in LGPL.

[jdegoes]

All right, I am out-numbered! I will lobby for Apache instead. Let’s keep this one BSD for simplicity.

[fommil]

fear not @jdegoes it will be distributed under the GPLv3 when it's in the ensime-server assembly jar :grin: