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.
import std / [parfor, syncio]
proc pfib(n: int): int =
if n < 2:
return n
var r = [0, 0] # the two sub-results; array of size 2
for i in 0 || 1: # i = 0, 1 in parallel
r[i] = pfib(n - 1 - i) # r[0] = pfib(n-1), r[1] = pfib(n-2)
result = r[0] + r[1]This is fib under this model. No Flowvars, no sync, enforced that the target expressions r[i] are not accessed in a racy manner.
for i in 0 || 1:this is not exactly obvious, would you mind elaborate on the construct?