Drop support for curried type lambdas

[smarter]

It's not clear at all how they should interact with higher-kinded type parameter inference, in any case they are likely to make it harder to abstract over type lambdas, and to require some uncurry and curry type functions. Their main use-case is reduced verbosity, but this can also be achieved by having some form of inline syntax for type lambdas like https://github.com/non/kind-projector#inline-syntax (related discussion: #2041)

[ghost]

Hi, like discussed in the gitter channel, I am likely to vote pro, with the restriction that mixing curried and uncurried versions is restricted (the scope of this restriction should somehow be defined).

You can always explicitly curry or uncurry as I did for the state transformer
type CurriedState = [S] => [>-->[- _, + _]] => State[S, >-->]

[ghost]

I would even argue to be able to define

type Curried = [M[_, _[- _, + _]]] => [S] => [>-->[- _, + _]] => M[S, >-->]
and
type CurriedState = Curried[State]

but that does not seem to work (yet (?))

[odersky]

In the interest of regularity I'd tend to leave them in.

[smarter]

Leaving them in will require work to make them function correctly, for example in #3061 we assume in various places that AppliedTypes are not higher-kinded.

[ghost]

Martin,

maybe, like I said before,only a limited amount of mixing should be supported (not sure)

in my GitHub project https://github.com/LucDupAtGitHub/Feature-Based-Functional-Programming-with-Dotty I encounter a situation:

class StateComputationTransformer[S, M[+ _]: Computation]
    extends KleisliStateProgramType[S, M]
    with Computation[StateTransformed[S, M]]
    with State[S, Kleisli[StateTransformed[S, M]]] {

that works, but using a curried StateTransformed and State

class StateComputationTransformer[S, M[+ _]: Computation]
    extends KleisliStateProgramType[S, M]
    with Computation[StateTransformed[S][M]]
    with State[S][Kleisli[StateTransformed[S][M]]] {

it does not

well: should it work [ maybe this kind of mixing is one step to far (?)

Anyway, I did not really need the curried version because I could explicitly use

type CurriedState = [S] => [>-->[- _, + _]] => State[S, >-->]

and

class RandomPrograms[>-->[- _, + _]: Program: CurriedState[Seed]]

where needed

[odersky]

Since they have been in for a while now I think we can close this