Make the usage of kind projections more consistent.

[peterneyens]

Like @inthenow said in #1069: it's probably better to be consistent in our kind projection syntax.

Since the Lambda syntax was used quite a lot more than the λ syntax, I changed the occurrences of the last to the first.

I have also replaced the last type lambdas in TransLiftTests by kind projections.

[non]

Hi @peterneyens, this seems OK to me. But would you mind distinguishing the type lambda parameters from normal types somehow? It's fine if we move away from greek letters but maybe we could use lowercase letters to help distinguish them?

For example, we might write Lambda[(x, y) => Xor[y, x]].

How do people feel about something like that? I'd also be fine using greek letters for the parameters (but using Lambda for the type lambda itself).

[peterneyens]

The type lambda parameters were indeed more easily visible with the Greek letters than with the upper-case letters.

I don't mind lower casing or using Greek characters for the parameters, but I hope you don't mind me waiting on other opinions (doesn't make much sense doing this work twice 😄).

[ghost]

from gitter:

• https://gitter.im/typelevel/cats?at=54d39e88ea831b7605fb20e7
• https://gitter.im/typelevel/cats?at=54d3a07bea831b7605fb213d
• https://gitter.im/typelevel/cats?at=54d3a1a044f4db8b5063b64c
• https://gitter.im/typelevel/cats?at=54ebc5f9ea450f2f20888ba1
• https://gitter.im/typelevel/cats?at=54d3a9ecea831b7605fb2390
• https://gitter.im/typelevel/cats?at=54d3aa6eadca701740eb497f
• https://gitter.im/typelevel/cats?at=54d3a69826bc541370bef668

Not sure if that helps or not :)

[codecov-io]

Current coverage is 88.35%

Merging #1079 into master will decrease coverage by 0.50%

1. 5 files in .../src/main/scala/cats were modified. more
   • Misses +4
   • Hits +24
2. 6 files (not in diff) in ...main/scala/cats/laws were modified. more
   • Hits -1
3. 2 files (not in diff) in .../main/scala/cats/std were modified. more
   • Misses +3
4. 3 files (not in diff) in ...n/scala/cats/functor were modified. more
   • Misses +10
   • Hits -11
5. 4 files (not in diff) in ...main/scala/cats/data were modified. more
   • Hits +2
6. 6 files (not in diff) in .../src/main/scala/cats were modified. more
   • Misses +6
   • Hits -4
7. 3 files (not in diff) in .../src/main/scala/cats were deleted. more
8. File ...cats/free/Free.scala (not in diff) was modified. more
   • Misses 0
   • Partials 0
   • Hits -1
9. File ...reeApplicative.scala was modified. more
   • Misses 0
   • Partials 0
   • Hits -1

@@             master      #1079   diff @@
==========================================
  Files           226        223     -3   
  Lines          2911       2808   -103   
  Methods        2859       2751   -108   
  Messages          0          0          
  Branches         49         52     +3   
==========================================
- Hits           2587       2481   -106   
- Misses          324        327     +3   
  Partials          0          0          

Powered by Codecov. Last updated by d541f5d...0bae06d

[ghost]

A few comments ^^ was about the general usage of Greeks in general (My IDE can't, etc). Hence, if you use greeks for the parameters, you might as well use them for the lambda, too.

One of my comments was they are confusing to newbies. Whilst I still hold to that, alot of that thought was based on code not using kind projector and using ascii symbols such as \/. There are no greeks below (using lower case), but OMG!

implicit def DisjunctionInstances1[L]: Traverse[({type l[a] = L \/ a})#l] 
  with Monad[({type l[a] = L \/ a})#l] 
  with Cozip[({type l[a] = L \/ a})#l] 
  with Plus[({type l[a] = L \/ a})#l] 
  with Optional[({type l[a] = L \/ a})#l] 
  with MonadError[\/, L] = new Traverse[({type l[a] = L \/ a})#l] 
  with Monad[({type l[a] = L \/ a})#l] 
  with Cozip[({type l[a] = L \/ a})#l] 
  with Plus[({type l[a] = L \/ a})#l] 
  with Optional[({type l[a] = L \/ a})#l] with MonadError[\/, L] {

But as cats does not make heavy use of ascii symbols, and does use Kind projector, I must say that I prefer

val asString: FunctionK[Id,λ[α => String]] = new FunctionK[Id,λ[α => String]] {

to

val asString: FunctionK[Id, Lambda[X => String]] = new FunctionK[Id, Lambda[X => String]] {

Luckily, it's not my decision - tough one 😄

[ceedubs]

I'm pretty ambivalent as to whether greek letters are used or not, but I echo @non's request that type lambda parameters are clearly distinguishable from "normal" types.

[peterneyens]

After the consensus on using Greek characters on gitter yesterday, I have changed this PR to use the λ[α => G[F[α]] syntax.

The most important points for this decision are (if I summarized the discussion correctly) :

• The type lambda parameters need to be clearly distinguishable from normal type parameters.
• The kind projector plugin makes it (to ?) easy to write type lambdas, so using Greek characters slightly raises the bar again.
• The Greek characters show that something different is going on, making it easier to refer to the kind projector plugin from something like a FAQ.

[non]

👍 Thanks for this @peterneyens, and also putting up with our flip-flopping!

[non]

Unfortunately it looks like I just created a merge conflict by merging #1021. Sorry! I'll try to fix it ASAP.

[peterneyens]

I saw that one coming indeed 😄 because the compose methods probably contain a big part of thet type lambdas, I hope I solved the conflicts.

I was also thinking that I could at a scalastyle regex check for Lambda[, but scalastyle doesn't seem to be working in cats here, I don't know if I am the only one having this problem ?

[ceedubs]

Great. Thanks, @peterneyens!