hkt
hkt copied to clipboard
derive4j
Higher Kinded Type machinery for Java
Minor change to generated casting methods (to handle [KindedJ encoding](https://github.com/KindedJ/KindedJ/blob/master/kindedj/src/main/java/io/kindedj/Hk.java#L28) directly) but should be source compatible (tested on HighJ). Eg. for `Either` the generated code is now: ```java @SuppressWarnings("unchecked") static...
Hey guys, I'd like to turn on this feature in cyclops-react (https://github.com/aol/cyclops-react/issues/347), when I added the hkt project as a dependency and make cyclops-react Higher class extend org.derive4j.hkt.__ everything compiles...
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...
As @jbgi and I discussed on gitter. I wonder if we could get rid of a number of casts by instantiating TypeEq through method references....
This ```java __2 nasty() { return new __2() {}; } ``` compiles. It shouldn't.
That could be useful to enforce the use of a single representation of HKTs (i.e one of the three described here https://github.com/derive4j/hkt/issues/1#issuecomment-204116116) through a project
Not sure if this is the right place for this question. But is there a way to easily handle using HKT for classes we can not extend/implement __, __2, etc....
Local classes are classes declared inside methods or value constructors : there seems to be no use case for lifting those to type constructors.
Ensure all imagined misusing of the hkt interfaces are catched by unit tests.
Including a presentation of use-cases, links to prior art and papers, projects that use this lib.