Nim's macro system is very impressive and powerful. At the strict local level, macros can produce any kind of code. But, that particular code will never see the daylight, because it is consumed in the surrounding program. The code could be spared instead and reused/compiled later again. So, how to get the code?
A fairly ad-hoc solution: Convert the rendered code into a string with toStrLit and write it into a file (with extension .nim).
Are there better, more formal ways to handle that? Is there an idiomatic "Nim way"?
you have the code. it's the macro code plus your call to the macro.
sometimes you might want to check the macro output with 'expandMacros but why would you need to store the output?
a macro call is more compact, readable, reusable and recompilable than the expansion of that macro call, surely.
Sounds interesting. Where can I find it?
I regard modules as heterogeneous type containers and therefore, it should be possible to type them. Modules as extended type classes, including interfaces, concepts and quantified, but restricted types.
Sounds interesting. Where can I find it?
Nim devel, directory compiler/ic, compile you program with --ic:on ...
I just keep on reading packed_ast.nim. There is no tree anymore. You converted the tree into a list (if I understand it correctly...). So the AST becomes an ASL. Sounds promising. You wrote elsewhere, that the packed_ast should replace the recent AST representation everywhere. Would this affect macros too?
Another question: Are generic types still possible in a PackedTree? So that replay will derive a couple of "reified" (generics removed) PackedTrees from a single one? And why is Deduplication an alternative?
The seq is still a tree but also allows for linear traversals as well as for recursive traversals. That's the beauty of it.
Would that affect macros too?
In a future that is a far away, yes. But in the meantime the macro system is not affected, even if the compiler were to use packed ASTs everywhere it could translate into the old NimNode structure for the macro system and then convert the macro result back into a packed AST.
Are generic types still possible in a PackedTree?
I don't understand this question -- the type graph is currently not affected and generic types continue to exist.
And why is Deduplication an alternative?
Well the problem is that you want to avoid the code bloat caused by two (or more) identical generic instantiations. You can either prevent these from being constructed in the first place (which is what we do, albeit we could be smarter) or you can deduplicate the identical instantations later. Deduplication is a more general but also more costly solution. For example, with deduplication you can also allow multiple different versions of a module to be compiled into the same program without code size and performance costs.
The seq is still a tree but also allows for linear traversals as well as for recursive traversals. That's the beauty of it.
The beauty is, as always, in the eye of the beholder. With packedAst you are going for 32bit padding now (20 Bytes...) which I regard as a good thing due to a low memory footprint. This could only be made possible because pointers are not involved longer, they are gone, finally! I recently implemented some type inference algortihms (Hindley-Milner extended) with some "packed" AST and I recognize this in your packed_ast.nim implementation. Much appreciated.
I don't understand this question -- the type graph is currently not affected and generic types continue to exist.
Well, there is a cbackend.nim in the package. It seems that .rod files are intended to be fed directly into the c codegen pass. I expected that these files are reified in the sense that every generic type got instantiated and therefore removed. I don't now about the exact name namling rules for procedures in the compiler. If the name reflects the type signature, e.g. gets formed with a hash of the types, name collisions would occur automatically and could therefore be detected and resolved. Again, I don't now about the cgen pass (or any other pass before, how many are they..) but I can partially follow the ic section, at least.