Couple of questions regarding the design decisions of HKT in fp-ts.

[SHND]

I was looking into how Higher-Kinded Types become possible in fp-ts. Amazing stuff. I have some questions:

1- Why Kind is using extends in both type parameter and it's definition?

For Kind in module HTK.ts I'm seeing we have:

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

Doesn't the extends in the type parameter enough? I mean why not:

type Kind<URI extends URIS, A> = URItoKind<A>[URI] 

2- Why do we need HKT definition, isn't Kind enough?

Basically what scenario the code below is not supporting?

type Kind<URI extends URIs, A> = URItoKind<A>[URI]

type URIs = keyof URItoKind<any>
interface URItoKind<A> {
  'Option': Option<A>,
  'List': List<A>
}

/***** Type Class *****/
interface Mappable<F extends URIs> {
  map: <A, B>(f: (a: A) => B) => (fa: Kind<F, A>) => Kind<F, B>
}

/***** Type Class instance *****/
const listMappable: Mappable<'List'> = { map: f => fa => nil }     // For quick drafting I used nil. Imagine a correct implementation
const optionMappable: Mappable<'Option'> = { map: f => fa => none }     // For quick drafting I used none. Imagine a correct implementation

/***** Utility functions *****/
function customMap<F extends URIs, A, B>(mappable: Mappable<F>, f: ((a: A) => B)) {
  return mappable.map(f)
}

const x1 = customMap(listMappable, (x: number) => x+1)(cons(1, cons(2, nil)))
const x2 = customMap(optionMappable, (x: number) => x+1)(some(2))

console.log(x1)
console.log(x2)

3- Why do we need URI in the Type Class instances?

I mean where do we find need to differentiate between Type Class instances, that we want to have URI in them?

interface Mappable<F extends URIs> {
  URI: F
  map: <A, B>(f: (a: A) => B) => (fa: Kind<F, A>) => Kind<F, B>
}

[SHND]

I found this thread too, but I didn't really get my answers. Can someone give me an example in which my snippet code above does not cover?

#1684

[SHND]

Ok my good fellas, if questions 2 and 3 are your questions too, it means you haven't understood HKTs like me. I'm going to explain why, but please please let me know if I'm wrong again 😂:

• HKT represents Kind, Kind2, Kind3, ...
• HKT2 represents Kind2, Kind3, ...
• HKT3 represents Kind3, ...

It's called Higher-Kinded Type because if Kinds are like Type, Type->Type, Type->Type->Type, ... then Higher-Kinded Types look like (Type)->Type, (Type->Type)->Type, (Type->Type->Type)->Type, based on where do we put the parentheses starting from the beginning. Then

• HKT represents (Type)->Type, (Type->Type)->Type, (Type->Type->Type)->Type, ...
• HKT2 represents (Type->Type)->Type, (Type->Type->Type)->Type, ...
• HKT3 represents (Type->Type->Type)->Type, ...

Why this is important? Think about Functor. Functor works on Option and Either.

• Option kind is Type->Type
• Either kind is Type->Type->Type

Implementing map function for Option Functor is easy:

const optionFunctor: Functor1<'Option'> = {
// map: <A,B>(f: A=>B) => Option<A> => Option<B>
   map: <A,B>(f: A=>B) => Kind<'Option',A> => Kind<'Option', B> = ...
}

What about map function for Either Functor?

const eitherFunctor: Functor2<'Either'> = {
// map: <E,A>(f: A=>B) => Either<E,A> => Option<E,A>
   map: <E,A>(f: A=>B) => Kind<'Either',E,A> => Kind<'Either',E,A> = ...
}

How can we abstract Functor1, Functor2, ... and have only one Functor definition? By introducing HKT (Higher-Kinded Type)

interface Functor<F> {
   map: <A,B>(f: A=>B) => HKT<F,A> => HKT<F,B>
}

In another words, no matter how many type parameters our type constructor receives (Option is 1 and Either is 2, ...) Functor only changes one Type parameter (first one) and keep the rest fixed, or in another word it works over HKT.

How about BiFunctor that its map function changes 2 type parameters? Then our abstraction should at least be over the first 2 type parameters which are HKT2.

Now you can implement cool functions over Higher-kinded Types and not only a specific kind like Type or Type->Type or Type->Type->Type. An example of this is the overloaded lift function like in the documentation of fp-ts.

[SHND]

@gcanti Can you please check if what I've just wrote is correct?

[gcanti]

In general, there is a mix of historical reasons and performance considerations for the type checker. Keep in mind that this system was designed several years ago and it needs to work with [email protected] as well.