> To give this discussion a more productive turn: Yes, I know Nim is flawed > too, I'm working hard to mitigate its many problems.
"Sometimes it's a flaw, but then, it becomes strength" ... Is this Zen too? I don't know. I could not get the [T] Syntax for a long time, because I didn't believe that it would work. Obviously, I was wrong. Now I regard parametrized modules (not exactly parametrized but modules with parameters instead) as implicit (hidden) typeclasses. If I am right: How could modules provide more structural information? Before (re)constructing them at user site (concepts), I would like to give them a shape in the defining module (Haskell) Some lowhanging fruits for modules : Instead of writing [S] [T] [U] all the time through the module, these type parameters could be declared on top of the module as wildcard-like "free running type parameters". Then, the vast majority of the [S][T] clutter before procs would disappear. If the caller wants to declare them upfront and there are several of them ? Alphabetic order seems reasonable. Much can be done with the most underrated statement in (since 2000) upcoming languages : The `import` statement. The `import` statement provides a class or typeclass with additional types and functionality. If more than one typeclass is defined in the module (we don't have explicit typeclasses in Nim actually ) every typeclass should get its own import statement. So, within the import header, some properties of the module get revealed. There are other things to mention too: The `sealed` property in Scala and so on and so on. If , for instance , no typeclass gets formed within a module? Then, the `import` remains a "bare" `import`. Andrea's "patty" via an extended `enum` (this comes from Haxe...) <https://code.haxe.org/category/functional-programming/enum-gadt.html> ...allowing for Scala's "case-objects" and even GADTs. The wishlist is potentially infinite of course. So, Nim might see some extensions in the future, without breaking recent code. But Nim is not "flawed". The fact that the language is still extendable is a good thing (despite being a nightmare sometimes) .
