Lots of inconsistencies have been found
Can you elaborate... inconsistencies found in what? Nimony? the stdlib? other code? Or are you saying generally that the linter does its job well?
Compile times are currently not too good as the priority is feature development and bugfixes. Nothing has been optimized yet, and I'm sure that there downstraight silly bugs that keep us from reaching speed.
Reaching Delphi's speed, probably never, Nimony does much more (generics, meta-programming, contract checking, plugins...). But! I'm sure we'll get it to "unnoticably fast on a modern machine".
"src/hexer/lambdalifting.nim", "src/hexer/destroyer.nim", "src/hexer/xelim.nim", "src/hexer/desugar.nim", "src/hexer/cps.nim", "src/hexer/duplifier.nim", "src/hexer/nifcgen.nim", "src/hexer/eraiser.nim", "src/hexer/iterinliner.nim", "src/hexer/constparams.nim", "src/nimony/sem.nim", "src/nimony/semdecls.nim", "src/nimony/controlflow.nim", "src/nimony/deferstmts.nim"
However, the validator is in early stages and not complete. It's quite far away from formal verification, but it's much more than primitive linting.
A linter / validator is cool. Maybe it could support different styles.
Would it for the Linter be possible to check for example for the var / let - difference. That is, single assignments that are unnecessarily declared with var?
In my older code i wrote declarations all up-front en didnt care about let/var, but recently i have done so for easier refactoring and performance. Maybe I will write a procedure to move the variabele-declarations to the latest possible position.
The validator is specifically for plugin-development and Nimony compiler code checking. It is focussed on correct NIF processing logic and enforcing a style that is more likely to be correct than wrong. In fact, it might result in a "restricted Nim" variant that can be proven correct. But even then, again, "restricted Nim" is all about compiler development, it is for proving compiler logic correct.
If you want a general purpose Nim linter, you can then later write one as a Nimony plugin and the validator might find bugs in your plugin code.
Unfortunately it does not bootstrap on Windows yet.
2 hours later...
Bootstrapping now works on Windows.
Wow. That's godspeed.
Well I had a strict "no hacks allowed" policy for Nimony and it payed off big-time. Claude loves NIF27 and my codebase.
Of course, what amounts to a "hack" is somewhat subjective and changes whenever you come up with a better solution.
What's the status of range/slice subtypes, and their current priority? Using Nimony right now and it'd be nice to have them again. e.g.:
"word"[0..2] == "wor"