Kind vs HKT - compare and when to use which?

[twitu]

I've been trying to understand when to use Kind and when to use HKT. Here's my current understanding -

export interface HKT<URI, A> {
  readonly _URI: URI
  readonly _A: A
}

HKT gives the the type a specific shape and specific names to the fields. It can be considered a low level kind definition to create my own types. If I use this structure I will still get the advantage of all the type classes defined for HKT.

export declare type Kind<URI extends URIS, A> = URI extends URIS ? URItoKind<A>[URI] : any

Anything with a type parameter A that can be added to URItoKind can be looked up from it as a Kind. But Kind too implements many type classes. Almost identical example -

export interface Functor<F> {
  readonly URI: F
  readonly map: <A, B>(fa: HKT<F, A>, f: (a: A) => B) => HKT<F, B>
}

export interface Functor1<F extends URIS> {
  readonly URI: F
  readonly map: <A, B>(fa: Kind<F, A>, f: (a: A) => B) => Kind<F, B>
}

However looking at a few data types e.g. Either, Json, Option they don't have the fields of HKT so can only be used with Kind related typeclasses.

My question then is when to Kind and when to use HKT? Are the HKT related typeclasses available for backward compatibility?

[gcanti]

See https://gcanti.github.io/fp-ts/guides/HKT.html

[twitu]

I re-read this and I'm still not sure what it is that separates these two. 😅

The only difference I can see is that HKT "prescribes" a shape for the data i.e. _A field must be of A and so on, while Kind does not do so and leaves the shape completely up to the user.

The benefit I can see with HKT is that since it's shape is known a lot of type classes can be auto-derived.... but I didn't see auto derivations of common type classes for HKTs which is what has me confused.

[twitu]

Aah ok one more advantage is that HKT are not looked up from the URItoKind mapping, so anything not declared there can still be handled using HKTs... but when would that be the case hmmm 🤔

[SHND]

@twitu Please check #1890 (comment) see if it make sense.