Add FunctionN.liftN, parLiftN

[kubukoz]

liftN is just like mapN, but it should provide better type inference - if you have 6 effects to put in a tuple, you can make a mistake in one and suddenly the whole tuple no longer has a mapN methods. With liftN, you put the function first, and only then pass the (wrapped) elements.

Consider this:

case class User(name: String, age: Int)

def validateName: ValidatedNel[String, String]
def validateAge: ValidatedNel[String, Int]

User.apply.liftN(validateName, validateAge): ValidatedNel[String, User]

tupledF is the same thing, but when your tuples are already in an effect - this can happen if you're unable to do .tupled (e.g. combining cats-parse's Parser + Parser0 - cc @johnynek) or you're just not in control over how the tuple is produced in the effect. tupledF has been removed from this PR, we can revisit it in the future.

[kubukoz]

I think I'd like to add the parallel versions too, but I don't want to invest additional time without some buy-in from the maintainers: let's talk about these first :)

[johnynek]

I like the idea.

I don't think I like the tupledF name. I think we should iterate on that a bit.

Maybe mapTuple? I don't know.

[kubukoz]

I'm fine with pretty much any names ;)

[joroKr21]

Related: https://github.com/typelevel/kittens?tab=readme-ov-file#lift-examples

[kubukoz]

Related: typelevel/kittens#lift-examples

that's pretty cool, I didn't know about it. Frankly I'd still like to have something like this PR in cats because not everybody uses kittens, plus liftN has slightly better UX because of:

• no tupling
• no Applicative[TypeConstructor], you start with the function you want to apply, just like if you were to apply it directly with no effects

[joroKr21]

Sure, I'm not arguing against this PR - just pointing out one could use kittens in the meantime.
Is there any difference between f.liftN.tupled and f.tupledF - i.e. do we need the extra boilerplate and strange name?

[kubukoz]

Is there any difference between f.liftN.tupled and f.tupledF - i.e. do we need the extra boilerplate and strange name?

@joroKr21 f.liftN[F].tupled (which is probably (f.liftN[F] _).tupled without -Xsource:3 in pre-3.x Scalas) is ((F[A], F[B])) => F[C], f.tupledF[F] is F[(A, B)] => C.

That said, tupledF offers less of an improvement over a simple map:

• (??? : F[(String, Int, Boolean)]).map(fapply3) fails with found : (A, B, C) => T, required: ((String, Int, Boolean)) => ?
• fapply3.tupledF(??? : F[(String, Int, Boolean)]) fails with found : F[(String, Int, Boolean)], required: ?F[(A, B, C)]

They may both have merit, though: ftuple.map(f) focuses on the inputs and lets you pick a function, whereas f.tupledF(ftuple) focuses on the function, letting you pick the arguments.

I don't have a strong opinion on whether tupledF needs to stay, personally I'm in it mostly for liftN. Perhaps it's best to focus on one thing and let the other one go until we find a more compelling reason to have it.

[kubukoz]

Added parLiftN for good measure.

[joroKr21]

Ah ok, the implementation is Functor[F].map(t)(f.tupled) which is the same as t.map(f.tupled) or f.tupled.liftN. Also related to Functor.lift which has no syntax though. It seems like too much hassle for minor details of syntax.

[TonioGela]

+1 on this to re-raise attention :)

[kubukoz]

Removed tupledF so now we only have liftN and parLiftN - shall we get this merged?

[joroKr21]

LGTM

[kubukoz]

merging with main apparently broke something, I'll take a look.

[kubukoz]

cats.jvm.tests.FutureSuite failed, but I don't think it uses the new functions. Could it be a flaky test?

I forgot to write down the failing hash and the logs are now gone :(

[joroKr21]

Here is the log: https://github.com/typelevel/cats/actions/runs/8066611292/job/22035078228#step:13:7049

==> X cats.jvm.tests.FutureSuite.Future: coflatMap.coflatten throughMap  3.013s munit.FailException: Failing seed: _syITpm-TcruL5pZb_9QYj5RRgP3qQgh3LgMILjdKuM=
You can reproduce this failure by adding the following override to your suite:

  override val scalaCheckInitialSeed = "_syITpm-TcruL5pZb_9QYj5RRgP3qQgh3LgMILjdKuM="

Exception raised on property evaluation.
> ARG_0: Future(Success(1))
> Exception: java.util.concurrent.TimeoutException: Future timed out after [3 seconds]
    at munit.ScalaCheckSuite.propToTry(ScalaCheckSuite.scala:98)
Caused by: java.util.concurrent.TimeoutException: Future timed out after [3 seconds]
    at scala.concurrent.impl.Promise$DefaultPromise.tryAwait0(Promise.scala:248)
    at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:261)
    at scala.concurrent.Await$.$anonfun$result$1(package.scala:201)
    at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:62)
    at scala.concurrent.Await$.result(package.scala:124)
    at cats.jvm.tests.FutureSuite.cats$jvm$tests$FutureSuite$$$anonfun$eqfa$1(FutureSuite.scala:45)