<@U7QUW41HP> why do you think is terrifying? Arro...

# arrow

[raulraja]

@noncom why do you think is terrifying?
Arrow is still in design phase and it's a lib in a lang that does not supports higher kinds.
For the names I have not come across consistent names for Higher Kinded Types before either. I hear people referring to them as Kinds, Type constructors, Higher Kinded Types, Generics of a Higher Kind.

What is the benefit of using HK<OptionHK, A> over Kind<ForOption, A> or its short form OptionOf<A>?
And ultimately what would you propose as a better name of none of those make sense currently?

[noncom]

Well, I will just enlist some of my thoughts that come to my mind when I think about it.

I think that the new naming obscures the meaning.

The benefit of HK<OptionHK, A> is that it is exactly what it reads. The new naming substitutes one concept and its natural name HK with three different names Kind, For and Of. Now in order to understand what actually is behind a particular word of the three and its implementation of a higher kind, one has to remember that the word For or Of means higher kind and then think of how a higher kind (one concept) is interpreted and named in each particular situation. For each of these situations you have to build a separate explanation.

I don't understand how it will help non-FP people because the naming will lead them even more astray. The naming won't affect them if they use the library only for its datatypes. But how are you going to explain the difference between Option<A> and OptionOf<A> which both are perfectly valid English and mean the same thing, to such people? Just say something like "hey, just use Option<A>, you'll never need OptionOf<A> because you don't understand type theory anyway"? And from the pov of English EitherOf does not shine either.

And if they somehow get into working with higher kinds, they have to learn the theory anyway. And if they learn the theory, you'll have to explain to them that OptionOf<A> is really a "higher kind for higherkind-option of A", which means HK<OptionHK, A> which is exactly what it was before the renaming? So, you have enumerated several examples of how higher kinded types were named in various places. Well, now you can add at least 2 more to them.

As for me, I can't see a better name than it used to be with HK. It was minimal, it was functional, it was clear. I kinda understand that Kind<ForOption, A> should be read as something like "higher kind for option of A", but beginning class names from auxiliary words like "for" and "of" is something that is not usually done, and for a good reason. Perhaps, if HK is bad, then simply Kind is a better alternative to substitute it with.

Why it terrifies me: because in my opinion it makes it harder to read, it disinforms people, and it does not encourage them to learn and understand. And that the decision was made for a library that has a definitive place in such an important language as Kotlin.

Now, I have expressed my concerns upon encountering this. I think that if you do this, you see good in this. The only good that I've heard is that it will help to popularize the library. Well, I guess you have the right to do it this way. I think that some people will like it and others will adapt. But this is distortion.

[noncom]

PS: I might be wrong or exaggerating too much in any or all of this. I hope for this.

[noncom]

I know that this is done with a good wish for improvement and making things better... and it is likely that the intent is to give semantic names rather than constructive. This is the trade-off: introducing new instances of semantics makes one obligated to learn it and accept it as it is, while constructivism makes one to understand elements and their relationships.

[pakoito]

It was minimal, it was functional, it was clear.

It was not clear for anyone who didn’t come from an FP background. We got plenty of complaints over a whole year and it was hurting adoption. That’s it all boils down to.

[pakoito]

The libraries objective is adoption and widespread use, all within a degree of correctness. There are plenty of instructive academic experiments around people can learn from, but that’s not the target here. Adoption first, learning afterwards.

Me and the other maintainers are willing to fight over whether we should provide an Option#get method (we shouldn’t!), but naming is something that comes from the users, and we had originally overlooked. After spending time with them at conferences and events, this was a way of removing blockers on adoption past the initial euphoria and think about long term.

[pakoito]

These blockers are not only for us, but for people with FP backgrounds that’d like to start using it in their company and are limited by the knowledge pool. Having a lighter ramp-up than going full-on Haskell and having studying to use the library is what will help the paradigm flourish.

[raulraja]

@noncom thanks for the detailed exposition. I see your point. I also see @pakoito point here and I think this issue could also be discussed as we gear toward 1.0.
@noncom if you like to expose your concerns as an issue in github we can have others from the community also express their thoughts and perhaps all together come up with better names for this concept which is foreign to many in Kotlin. We can have a table with a few proposals where to iterate to define better names for:
Kind<F, A> -> A Higher Kind value
ForData -> Type in Higher Kind Position. Ex: Functor<ForData>
DataOf<A> -> Non concrete but known data value in higher kind position. Alias for Kind<ForData, A>
DataPartialOf<A> -> Partially applied type constructor, appears in kinds with arity > 1

[isto]

I find the new type names easier to read and use, in a language where higher kinds are not (yet) natively supported, I end up reading the source anyways. I also think people with FP background will have no problem using their IDE to check the source if something is not directly intuitive. Of course, this all is very subjective.