I am not sure if I understand correctly what you m...

# arrow

[simon.vergauwen]

I am not sure if I understand correctly what you mean by syntax for functional types

[elizarov]

https://kotlinlang.org/docs/reference/lambdas.html#function-types

[simon.vergauwen]

Okay I did understand correctly 😄 But why would the syntax differ for functional types? i.e. fun <F<_>, A, B> lift(f: (A) -> B): (F<A>) -> F<B>

[elizarov]

What is F<_>? We don’t have a syntactic tradition in Kotlin to use _ to denote formal parameters.

[elizarov]

Functional types in Kotlin, for one, are not denoted like this: f(_)

[elizarov]

I know Scala does it. But we are talking about Kotlin here and how its syntax should be consistent and understandable. That is why it is going to be a big debate on how to denote HKTs syntactically.

[simon.vergauwen]

I understand but because nothing similar is available currently I think new syntax would be the straight forward. And in my opinion F<_> would be the most clear and the most straight forward.

[elizarov]

We already use _ in completely different sense. I’m not sure it is going to be clear for people who don’t know Scala.

[simon.vergauwen]

If you look at https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md it introduces higher kinded types with associated type and I find it really unclear.

[elizarov]

I, for one, not a big fan of associated types, either

[simon.vergauwen]

_ being used for ignored params in desctruct?

[elizarov]

and in lambdas

[simon.vergauwen]

it is going to be clear for people who don’t know Scala.

[simon.vergauwen]

Unless they know HKTs from another language it is going to be unfamiliar.

[elizarov]

If they know Haskell, which is much more likely (since many universities teach Haskell in their FP course), then they would not understand F<_> either. Haskell’s syntax for type constructors is consistent with Haskell’s syntax for functions.

[elizarov]

I don’t say here I know how to do it better. I say, that just copying it from Scala might not be the best idea

[elizarov]

In Kotlin we have an explicit goal of not turning it into yet another Scala. Kotlin, first and foremost, must be understandable and approachable by masses.

[simon.vergauwen]

And that is one of the reasons I really like Kotlin.

[simon.vergauwen]

Coming from a Java background I feel F<_> or anything similar that syntactically “says” a type F with a whole in it would feel best understandable.

[simon.vergauwen]

Having no note worthy experience with Haskell I feel something like * -> * would feel quite strange. For sure there is no Haskell in Universities where I live.

[raulraja]

Personally I'm not concerned so much about syntax and I think the key is the possibilities it opens. I'd be happy if there were there regardless of the syntax. F<_> kind of shows it refers to a whole in F and F<A> a concrete type when F is applied with A, but probably is my bias toward being familiar with Scala. Looking forward to see what other people may propose 🙂

[Jorge Castillo]

Isn't it a possibility to add this in a separate artifact for FP features on top of the language? Might not be needed to have it as part of the Kotlin stdlib.

[raulraja]

This would not be part of the stdlib but the actual compiler grammar and compilation. Most lib authors will probably take advantage of such features since it will allow them creating libraries where users may choose different data types as return types. For example with type classes and HKs you can write libs that abstract away asyncrony making those libs usable both in async/reactive context or in a single threaded contexts.