Bring Kind-projector to LBS and TLS compilers. about kind-projector HOT 11 CLOSED

So here's a quick overview of some questions that I think need to be answered by a SIP:

1. Are we committed to representing type lambdas with the projection encoding (e.g. ({type L[x] = (x, x)})#L)? Or are we going to add a new AST node such as TypeFunction above? There are known issues with the type projection encoding, but on the other hand most people seem to be doing OK and adding a new node will require more design work and testing.
2. Are we committed to the kind-projector function syntax (e.g. Lambda[+a => F[a]])? In the Typelevel fork I think we wrote this as [+a] => F[a] -- is it worth it to change the parser? The former reserves some new names but is currently used in codebases. The latter is closer to what the Scala compiler currently emits (and terser) but is a new syntax.
3. Are we committed to the kind-projector wildcard syntax (e.g. Either[Int, ?])? This seems like the best we can do, even in a SIP, but it does reserve an additional name (that may be used in some other codebases).

from kind-projector.

Continuing from above, there are basically two independent things we should consider:

• Keep or change the syntax?
• Keep or change the encoding?

Here's how I'd characterize the four options:

1. First-class type functions This would be a break with kind-projector, introducing new AST nodes and terser type function syntax. This is nice for the language but puts stress on the existing community. This is what Jason Zaugg sketched out above.
2. Reify status quo This would involve moving the existing kind-projector phase into the compiler. It provides complete continuity to the community, but is a bit ugly for the language (and may not be accepted).
3. Improved encoding This would involve keeping the existing kind-projector syntax, but improving the AST encoding of type functions. This provides continuity for the community, but has the syntactic downsides of (2).
4. Improved syntax This involves changing the syntax but not the encoding. This puts a burden on the community, keeps the look of the language clean, but has the same problems with using type projection to encode type functions. This is what was done for TLS in the existing PR.

from kind-projector.

One final note -- if we did change the syntax of type functions I think it would be important to back-port the feature to 2.10 and 2.11. Otherwise most projects will continue using kind-projector until support for those versions of Scala is completely dropped.

(If we don't change the syntax then projects can conditionally use kind-projector based on Scala version, or kind-projector can disable itself when it detects a Scala version with built-in type lambdas.)

Since kind-projector supports 2.10 and 2.11 it would be relatively easy to support those versions using the projection encoding (changing the parser for 2.10 - 2.12 is doable). Adding the AST node to all three versions may also be possible, but could be more work (I'm not sure).

from kind-projector.

My concern would be if it somehow gets in the way of continued kind-projector development. If extensions to it could still be done in a compiler plugin, or if its development within TLS could be as fluid, then great. Just worry about tying things to the release cycle of the compiler, and possibly requiring extra overhead (like more SIPs) going forward.

from kind-projector.

@sellout I think moving type lambdas into the compiler would slow development on type-level type lambdas. But I don't think it would necessarily slow down other things, such as @paulp's support for polymorphic lambda values.

Are there features related to expressing type lambdas at the type level that we still need?

from kind-projector.

Is there a partial approach where aspects of this could be moved into the compiler in a manner that wouldn't interfere greatly with continued development on type lambdas?

from kind-projector.

@non polymorphic lambdas was exactly what I was thinking of – I don’t know of any type level features that may be needed.

from kind-projector.

@sellout I think having the plugin detect built-in support (or not) and just provide whatever was absent could work, assuming we keep the existing syntax. We need to hear from the compiler team -- if they don't like the existing kind-projector syntax then we may have to move to something else.

from kind-projector.

I'm kind of torn here. I think the plugin is a great 95% solution but I expect 100% from a language feature, and I don't expect to ever get that last 5% if we just drop it in (2 above). So I guess I would prefer to see it done "right" (1 above) or remain as a plugin.

I'm also unsure that the engineering effort is really worth it. We'll have to put it behind a flag, nd the ability to turn it on via scalacOptions instead of addCompilerPlugin isn't much of a value-add for me.

from kind-projector.

@tpolecat Yeah, I'm a bit torn too. However, I think it would be possible to have the plugin compile existing code into the "new scheme" when needed, so we could sort of transition code from a backwards-compatible syntax to a newer syntax. (That's something I only thought of after writing the options above.)

I agree it would be a bit of work.

from kind-projector.

The plugin is fine for Scala 2. Making it a language feature has now happened in Scala 3.

from kind-projector.