CartesianBuilder's .map is slightly irritating

[tpolecat]

So, when we copied scalaz's ApplicativeBuilder syntax (a |@| b |@| ...)(f) we changed the final .apply to .map which is an innocent but perhaps unhelpful change. My particular issue is that I'm trying to maintain code that needs to compile with both cats and scalaz; most code works fine just by changing/renaming imports, but this syntactic difference requires additional machinery.

Right now @rossabaker and I are probably the only people hitting these things head-on right now, but I imagine there will be more people porting code at some point and it would be nice to not make things harder unless there's a good reason.

So … might we consider allowing both .apply and .map here?

[rossabaker]

I'm currently experimenting with syntax to smooth the transition from scalaz to cats. (Somehow I missed CartesianBuilder thus far!). I've wondered about spinning this off as a library, with everything deprecated, so that s/import scalaz/import cats holds the developer's hand through finding the right cats calls. We could even go so far as to put them in cats for a more out-of-box migration assistant, though it does suck to approach a 1.0 with deprecated baggage.

[kailuowang]

Just want to link PR #1112 here since it proposes to rid of the |@| syntax.
Personally I have no problem with the |@| and I am okay with both apply and map

[julienrf]

Since the applicative builders work with applicative functors as well as with applicative contravariant and invariant functors, I don’t think it is a good idea to make .apply a shorthand for .map. The name .map, .contramap, etc. makes it clearer what the intention of the user is.

[tpolecat]

@julienrf ah ok, I didn't know there were other operations. That makes sense. Ok, I'm convinced.