An often undervalued feature of Nim is its effect system. I usually don't mark my procedures as either pure or having some effects, but I have seen the compiler infer it in the generated documentation. Still, there is something that is not completely clear to me.
How much does the effect system "work on its own"? Is it able to always infer effects, or does it sometimes need manual intervention? The risk that I see is that people do not often care anyway, and these leads to libraries without many effects annotations, if any. If the effect system is not robust in face of this, we may soon find ourselves painted into a corner where so many libraries have incorrect effect annotations that the effect system becomes unusable even for disciplined users. Everyone that has tried to graft an effect system on the JVM (even as basic as the IO type) can testify that the effort is destined to fail due to the fact it is today impossible to manually add correct effects for the whole JDK.
So, the question is: does the effect system need user help? If so, we should strive to promote the creation of correctly effected libraries. Otherwise, we should strive for correctly effected bindings to native C.
Very good questions. The effect system needs some help: Indirect calls and forwarded procs cannot be inferred, so the compiler bails out with "can have any effect". These calls are however very infrequent in Nim and so it works out really well. importc'ed procs are assumed to have no effect that is not explicitly listed, so few annotations are required here too.
It's true that most Nimble packages do not care about effects (yet?) and so applications which want to take advanatage of the effect system may need to patch them or use cast at strategic places to override the inferred effects.
I envision the effect system, in particular the tag system, to be used for maintenance. In the past I often had systems where would have loved to annotate some old code base and prove with the compiler's help that e.g. a subsystem cannot access a database. The strength of Nim's effect system is that it doesn't get in your way for prototyping and you can gradually introduce more discipline for a codebase.
Everyone that has tried to graft an effect system on the JVM (even as basic as the IO type) can testify that the effort is destined to fail due to the fact it is today impossible to manually add correct effects for the whole JDK.
shrug I cannot design a programming language by learning from Java's mistakes. It immediately leads me to the conclusion I should give the "average programmer" a lollipop and not a programming language.
The strength of Nim's effect system is that it doesn't get in your way for prototyping and you can gradually introduce more discipline for a codebase.
This is very good, considering how common is to just ignore the effect system until you actually need it! Still, I think we should promote the use of the effect system for those that wrap C libraries that do have effects, for instance database clients
I cannot design a programming language by learning from Java's mistakes.
I do not exactly understand what you mean here. What I was saying is that - if one is not careful - adding effects to libraries too late may be impractical. Languages different from Java that run on the JVM (e.g. Frege) already run into problems because of this.
By the way, what is the state of the stdlib? Are effects generally correctly annotated there (where relevant)?