# Are there any (long term) plans to add higher order generics (a.k.a. higher kinded types) to Julia?

**URL:** <https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [January 18, 2017, 2:46pm UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570 "2017-01-18T14:46:59Z")\
**Posts on this page:** 11\
**Page:** 3

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 29, 2018, 3:46pm UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/41 "2018-07-29T15:46:43Z")

</div>

> [@catawbasam](#):
>
> wrap-up work going on and probably not a lot of room in the short term for fundamental rethinking

You are of course right, but even if there was an opportunity for a major redesign, I am not sure this topic makes a compelling case for one — the software engineering problem is still unclear. Cf

> [@Are there any (long term) plans to add higher order generics (a.k.a. higher kinded types) to Julia?](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/25):
>
> It’s still quite unclear to me what problem you’re trying to solve here. It seems like you’re going to great lengths to shoehorn a Principia Mathematica style hierarchy into Julia for its own sake. But Russell and Whitehead didn’t want a hierarchy of types in the first place, they only added it to their logical system to avoid the construction of paradoxical sets. We don’t have that issue, so what problem does this rather complex proposal solve? As far as I can tell, allowing type parameters to …

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [July 29, 2018, 6:24pm UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/42 "2018-07-29T18:24:46Z")

</div>

Julia is sound—by which I assume you mean “consistent” since “sound” is a type system term whereas “consistent” is a logic term—because it exists in the real world. Any real system, even in a computer, by virtue of actually existing _must_ be consistent. This is because reality itself is consistent: different accurate descriptions of reality must all agree with each other. (If you don’t believe this then we’ve got deeper problems than whether Julia’s modeling of types is consistent or not.) You can no more create a paradoxical object in Julia than you could build one in your living room. I cannot create a type in Julia which both contains and does not contain itself for the same reason I cannot make a single-color chair that is both blue and red: if you construct a type object in Julia, it exists, and you can just check if it contains itself or not, just as you can look at the chair and see which color it actually is.

It is only in the context of formal systems like _Principia Mathematica_ that consistency even becomes a question in the first place because these systems are just a made up set of rules, and it’s not a given that they don’t produce contradictions. One way to look at the issue of consistency is that it is fundamentally about whether a collection of mechanical rules (i.e. a formal system) describe something which could potentially be “real”. The most basic way in which a formal system can fail to be realistic is if it is can produce contradictory statements about the reality it is supposed to describe. A formal system that allows a set that both contains itself and doesn’t contain itself at the same time, for example, cannot possibly describe anything “real” since in reality the set would either contain itself or not.

So asking about the consistency of Julia is the wrong question. Julia is guaranteed to be consistent because it exists. The question you should ask is whether the type system implemented in Julia can be mapped into a formalized set theory like ZF/C. We have every reason to believe that it can as long as you add non-well-founded sets to ZF/C (via any of the various anti-foundation axioms), which allows a type like `Type` which contains itself to be modeled. No one has proven this to be the case, but since the types which can be constructed in Julia are all finite, it’s pretty unlikely that anything really wild could possibly happen—there’s not a whole lot of controversy in the realm of finite sets.

---

<div class="post-metadata">

**Author:** ![Sighoya](https://avatars.discourse-cdn.com/v4/letter/s/a87d85/32.png) [@Sighoya](https://discourse.julialang.org/u/Sighoya)\
**Post date:** [July 29, 2018, 7:57pm UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/43 "2018-07-29T19:57:05Z")

</div>

@StefanKarpinski

Thanks for the long reply and the patience.  
I really meant “unsound” in the sense of:  
Does julia has no support for user defined non well founded sets because it would invalidate its type system otherwise?

@Tamas_Papp wrote:

> I am not sure this topic makes a compelling case for one — the software engineering problem is still unclear.

The discussion with @StefanKarpinski was not about HKTs anymore and I’m sorry for this.

To implement true HKTs we would need the complete support of function types which will (never) be the case from what I heard about @yuyichao and @jeff.bezanson

Whereas abstractions over parametric sets, e.g C{\_}, which is different than HKTs is possible, at least in my mind, but complicated due to runtime subtyping additional to parametric subtyping in julia.

---

<div class="post-metadata">

**Author:** ![TsurHerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsurherman/32/1234_2.png) [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)\
**Post date:** [July 30, 2018, 7:19am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/44 "2018-07-30T07:19:23Z")

</div>

I was toying with the following idea:

define \<: (less than or equal for types) arbitrary and dynamically and possibly more than once … so that it would be possible to define something similar too:

```julia
abstract type AbsInt end
abstract type Abs2Int end

struct Foo
    a::Int
end

set_ordering(Foo,AbsInt)
set_ordering(Foo,Abs2Int)

```

what are the drawbacks? or asking from a different direction, what are the benefits of having a single parent?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 30, 2018, 7:43am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/45 "2018-07-30T07:43:39Z")

</div>

> [@TsurHerman](#):
>
> what are the drawbacks?

```julia
bar(::AbsInt) = 1
bar(::Abs2Int) = 2

```

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [July 30, 2018, 7:55am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/46 "2018-07-30T07:55:50Z")

</div>

[https://github.com/JuliaLang/julia/issues/5](https://github.com/JuliaLang/julia/issues/5)

---

<div class="post-metadata">

**Author:** ![thautwarm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thautwarm/32/37760_2.png) [@thautwarm](https://discourse.julialang.org/u/thautwarm)\
**Post date:** [February 3, 2019, 4:57am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/47 "2019-02-03T04:57:56Z")

</div>

You might want to have a look at the lightweighted higher kinded types in Julia.  
PDF is available here:

> **[lightweight-higher-kinded-polymorphism.pdf](https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-kinded-polymorphism.pdf)**
>
> 267.81 KB

I have an article about this implementation coupled with type classes:  
[https://thautwarm.github.io/Site-32/PL/paper-reading-LHKP.html](https://thautwarm.github.io/Site-32/PL/paper-reading-LHKP.html)

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [December 2, 2019, 1:21am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/48 "2019-12-02T01:21:12Z")

</div>

I have been reading [ScalaFP: The Mystery of Scala's Higher-Kinded Types - DZone Java](https://dzone.com/articles/scalafp-the-mystery-of-scalas-higher-kinded-types) to understand higher kinded types. It looks Julia already has them

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [December 2, 2019, 1:34am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/49 "2019-12-02T01:34:07Z")

</div>

Yea it’s kind of funny what you take for granted when you make Julia your lingua franca. I remember reading about Scala’s type system preparing for my last job and trying not to have my brain explode. Ironically, when I started writing Julia it just made sense… Like the idea of using a higher kinded type was a natural one, I didn’t need to read a reference or anything, just knew what I needed, typed it and voila it compiled.

Scala though… Scala can be a very scary language. Makes all the intuitive things sound like sorcery, simple code like hieroglyphs, logical patterns look like strange attractors… Not always, but anyone whose seen someone other then themselves write scala knows these things.

---

<div class="post-metadata">

**Author:** ![thautwarm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thautwarm/32/37760_2.png) [@thautwarm](https://discourse.julialang.org/u/thautwarm)\
**Post date:** [December 2, 2019, 2:35pm UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/50 "2019-12-02T14:35:08Z")

</div>

Julia already has this: [https://github.com/thautwarm/HigherKindedPolymorphisms.jl](https://github.com/thautwarm/HigherKindedPolymorphisms.jl)

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [December 4, 2019, 1:09am UTC](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570/51 "2019-12-04T01:09:58Z")

</div>

If thats what higher kinded types are I’d retract my previous post I just meant abstracted generic types in a hierarchy.

[Previous page](https://discourse.julialang.org/t/are-there-any-long-term-plans-to-add-higher-order-generics-a-k-a-higher-kinded-types-to-julia/1570.md?page=2)