Furthermore the architecture changed to:
Nimony (frontend) ---> NJ ------+---> C / C++
^ |
| +----> JS
| |
Nim 2 (frontend) -----+ +----> native backend x86-64
|
+----> native backend ARM64So some development moved over to "NativeNif" which implements "NJ", is a new backend language to be targetted by both Nim 2 and Nimony.
Oh that's a good idea to create a common backend-node (if it is doable) to avoid double work. What does NJ stand for? No Joke? Or New Job :--)
Nice old-style relagram by the way.
In general, the refactorings all aim to refine the mentioned "NJ" IR that is the contract between the frontend and the backend.
It never occured to me to make them pragmas:
.dup: proc (...) = ... is too ugly and .dup: myDupImpl needs to infer the correct myDupImpl based on its signature.
Cool!
If a imports b, b imports c, and c imports a, should I mark all three imports with {.cyclic.}?
I wrote a blog post about Nimony's internals. First part is here
Great article, thanks!
I wonder what happens to nimsuggest in Nimony. I guess a full rewrite based on NIF will happen?
Goto-definition and find usages already exist:
https://github.com/nim-lang/nimony/tree/master/tests/nimony/track
You simply run nimony as a one-shot program, no service needed.
Cool!
So, I guess langserver is the one to be rewritten to support the new output format, which I suppose is NIF.