@Araq > language adoption is driven by external factors such as "companies behind it" > and "availability of library X" and "tooling support". Whether we like it or > not, "best type system ever invented" doesn't matter.
This sounds rather depressive to me, it sounds like: „We don‘t have the money, so we don‘t bother about a type system“ I‘ll play the optimistic part here instead, saying „ Well we don‘t have the money, so let‘s show up with smth good (perhaps new), especially let‘s do it (way) better than C++ does“ > The type systems I looked at start with a couple of unpleasing facts: There was a specific observation of @kcvinu: He observed that Nim takes the entire program as a monolithic block, therefore `import` would be in fact an `include`, that is another way to say: **Nim is lacking modularity**. And this is true. > Hindley milner type inference with overloading is NP complete. Hindley-Milner is with/without overloading in DEXPTIME anyway. However, in practice, it works almost within linear time. But Nim does not support HM anyway, so I don‘t see the argument here. > Yes, yes, Rust and Swift might do better (don't tell that the C++ people > though who routinely write code that Rust/Swift cannot express yet) What in particular does Rust any better? (It wasn‘t my claim though). Because they have traits? Or what is it? The (debatable) „borrow-checker“ aside of course. > Ocaml had to special case their support for "array of float" because it > relies on runtime type tags. It seems that OCAML introduced some ad-hoc polymorphism here for arithmetics. OCAML is not known for that, it monomorphizes anything, but why not. > Monomorphization should not be left to the optimizer for predictable > performance. If you enforce monomorphization Does Nim monomorphize early? Closing over generic parameters? This would be new to me, but I‘m eager to learn. And where is the „optimizer“? I think Nim does anything late (therefore the monolithic block) > leaving you with basically C++'s approach C++‘s templates – for the good or the bad, but they are working on types at least, offering a semi-categorical view onto the language. Skilled programmers can take advantage of it and they do combine templates into the wildest things. Totally unguarded of course, stressfull for the compiler and highly non-intuitive, therefore the required skills. BTW your „new concepts“ do contain an interesting feature, the `each T` . This would allow for intrinsic types. My guess here: It is „dangerous“ and expensive, you‘ll have to deal with sets and we‘ll see how long the feature will persist. Although `each T` aims to point in the right direction, I‘d go for something simpler. It is tiny, subtle and deep at the same time (and C++ doesn‘t have it). I‘d call it „hidden parametricity“ and I mentioned it several times in the forum. But I failed. Honestly, no one understood it. A presentation can be found, a bit lengthy, but precise and with logic derivations, in the following link (It is a slide show and I‘m not the author): <https://www.ps.uni-saarland.de/courses/seminar-ws02/ExistentialTypes.slides.pdf> The compiler essentially splits a module in two halfs with two different module names. Then it deliberately „forgets“ one of the names, depending of context. That‘s all? Pretty much it is, let‘s say 95% of it. Now you might argue that it is it already in the language, but it is not. With the feature, the visibility flag or „the star“ would not need to escape the type section of a module , because the compiler would then prefer to derive/complete the setting itself. > Feel free to fork Nim, patch its generics or enrich it with CPS and to show > us the way. None of both would address the issue. Disclaimer: If you want a categorical view of the feature, if you want types for entire modules and e.g. well-typed macros that could link two of them, the remaining 5% would appear with CPS in a pure logical sense (the slide show mentions it).
