stu002 is working hard on concepts now - IMHO he tries to squeeze smth out of them that they don't represent. Actually, I regard concepts more or less as cargo-cult : They try to imitate typeclasses or interfaces or whatever in that direction. They are implemented as constraints and therefore too weak (C++'s concepts are debatable as well for the same reason...).
Anyway, his eager work leads to new insights. An essential problem of concepts, if not the main problem, is visibility.
If we think about modules as a tree, data structures/typeclasses together with attached functions will be found deep in the tree. Concepts need to see them, therefore they will be found deep in the tree as well ( in the defining module or one level above). So, how to see them at top level (the root) ?
And how to take advantage of the functions and types given in a concept? Especially if the path to the functions is not revealed and therefore unknown?
Solution:
Advantages:
Some people want to make Nim "more popular". If a strong (new) selling point is needed: Here is one.
Anything has its pros and cons. So I'm waiting for your cons.
I should point out my use of concepts is not typical for system software or other mainstream software development in Nim. I'm trying to model structures from abstract algebra as I did in a limited way in Rust: https://gitlab.com/ornamentist/un-algebra
The issues I'm having with concepts reflect my lack of experience with the language as much as anything. I don't think I can move this project to the new concepts approach as it stands so I'd better give the whole concepts thing a rest for a while.
Many, many thanks to the language maintainers for creating such a fun language to use.
I should point out my use of concepts is not typical for system software or other mainstream software development in Nim. I'm trying to model structures from abstract algebra as I did in a limited way in Rust: https://gitlab.com/ornamentist/un-algebra
Nice work, I appreciate it. Very instructive to see the implementation in Rust. Abstract algebra is built on abstraction, so you need abstraction. You were attracted by Nim's concepts because they look like categorical descriptions. But as we have seen in your other thread (https://forum.nim-lang.org/t/8216) , concept matches do entirely rely on presentation/ visibility, moreover the presentation has to be in line for single-pass compiler. You have to do this yourself, you have to collect specific imports manually, the compiler will not help you. At the same time, you are (undesiredly) enforced to expose types otherwise being hidden in the module tree.
That's a very insightful summary of the issues around Nim concepts I've been encountering. Thanks for taking the time to write it up.
After experimenting with Haskell, Idris, and Rust to implement the mathematical structures I referred to, I found having typeclasses/traits/ad-hoc polymorphism changed the way I think about implementing abstractions in programming languages.
I started looking for the "laws" to accompany each abstraction and encoding those laws in generative tests. I can see now why the creators of Swift speak in terms of "protocol oriented programming", protocols being their version of traits/typeclasses.
I understand Nim is not Haskell or Swift and we shouldn't create language features just because some other language has them. Those other languages have also struggled over the years to find the best way to incorporate ad-hoc polymorphism in their type systems.
Having said that, I feel there is a place or some kind of ad-hoc polymorphism in Nim and concepts are a good start. My (very informal) wishlist for concepts (old and new) would be:
Whatever happens with concepts Nim remains a fun and powerful language. Thank you to everyone who has made it so.
Yes -- and very good too!
I'll probably end up using emmy as well as some modules of my own. I think you're going to have the same issues with migrating the emmy concepts to "new" concepts that I've been having.