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.
Progress: Nimony now implements sum types and pattern matching
Wow!
Can I like this twice?
stable text-based IR
llvm ir is not stable, though - they make breaking changes every few releases so you have to target a specific/locked llvm version.
syntax of it has been stable
syntax may be stable but the specifics are not - ie several things have changed over the years, they removed typed pointers, the syntax for debug information got changed completely, aliasing propagation etc .. there is indeed significant overlap between the versions but also significant change when you start using anything beyond the most trivial expressions - they are not afraid to break backwards-compat in this format if they feel they have reason to - you know, nlvm has had to deal with this over the years as well but it's insulated from many of the changes because it uses the API instead to generate things.
This is also the point: they see the IR as version-specifc because they typically use tooling to generate it - the fact that the test suite contains IR is irrelevant, they regenerate the test suite on demand.