Support for higher kinded types with arbitrary type arguments.

[jbgi]

Let's assume we offer interfaces up to __n (currently 5, soon 9).
There will be a day when someone would need to create a class with n + x type parameters (x >= 1).
We cannot add new interface infinitely, so there must be a way to cope with this situation.
My take would be that if a class has more that 9 type parameters then the higher kinded interface will only expose the last 9 type parameters, and the first "non hkt" type parameters would need to be backed in the type constructor witness in one of the two following way:

class WildType<A, B, C, D, E, F> imlements __5<µ<A>, B, C, D, E, F> {
    public static final class µ<A> {}
}

class WildType<A, B, C, D, E, F> imlements __5<__<µ, A>, B, C, D, E, F> {
    public static final class µ {}
}

The later encoding is more consistent with the hierarchy and eventually allow to abstract over all type parameters, but the first one may be simpler for types with lots of type parameters.

[clinuxrulz]

(2) is fine. You can actually live with just __, the others are just for convenience.

That is you can define public class StateT<S,M,A> implements __<__<__<StateT.µ,S>,M>,A> { ... } and everything will still work out fine.

[clinuxrulz]

And (2) is actually more safe. It allows you to define abstraction that can disassemble type parameters all the way. (Like how Category disassembles the last two type parameters)

[jbgi]

@clinuxrulz true, but if we allow, eg.

Either<A, B> implements __<__<µ, A>, B> {}

then we must get ride of https://github.com/derive4j/hkt/blob/master/src/main/java/org/derive4j/hkt/__2.java#L11 and friends:

  static <f, A, B> __2<f, A, B> coerce(__<__<f, A>, B> fab) {
    return (__2<f, A, B>) fab;
  }

that would then be unsafe. But maybe we are ok with removing those coerce methods...?

[clinuxrulz]

I have to have more of a think about it later. I got to go to work soon. But at the moment I would argue to keep the coerce methods and that they are actually still type safe. Remember that __ is a type level function, and as the same with regular functions you can have curried and uncurried forms (at least as practiced in Java). Also remember __2<f,A,B> inherits __<__<f,A>,B> .

[clinuxrulz]

Sorry. You are correct. It would mean dropping those coerce methods you mentioned. (Class cast exception)

[clinuxrulz]

I would vote to drop those coerce methods in __2, __3, etc. But wait to see what others think. One place I remember those coerce methods coming in handy was arrow transformers, but you don't really need them, you could do without.

[clinuxrulz]

Just a thought. If we choose to stop at __5 and go no greater, and document that we will NOT go larger than 5 EVER. then if someone needs 8 they just do __5<__3<h,A,B,C>,D,E,F,G,H> and everything remains type safe. Would just to make sure to have an absolute limit that never goes higher and people can just use the nested case when they do need to go higher.

We could stop at __9 and just document that we will never go larger than __9 EVER, and people can just use the nested style for larger than __9.

[jbgi]

@clinuxrulz this is also exactly what I had in mind!
I think we can go to __9 just to make the situation happen very rarely.

[jbgi]

For a practical standpoint, even if we don't support arbitrary number of type parameters we should aim to support up to 62 (as it is currently the limit for haskell tuples, cf. https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/src/GHC.Tuple.html#Unit).