4 ms·

I have thought a lot about meta programming and the best way to do it (I participate in the ISO C wg14) and I dislike macros, templets and every other attempt I

I have thought a lot about meta programming and the best way to do it (I participate in the ISO C wg14) and I dislike macros, templets and every other attempt I have seen. The best solution I have found, disregarding of language, is to use the same language to write a program that generates the code you need. Then you can compile, and debug them separately using the same workflow, and each program can be clear and simple to read. Its not sexy or clever, but it works and anyone can understand what is going on. Almost always that turns out to be the most important thing.

jesse__ 4y ago
I definitely agree. I'm actually in the middle of writing a C metaprogramming runtime (effectively a parser that spits out an AST) which is useful for writing such programs. Also, unrelated, but I miss watching your streams on Twitch, assuming you're the same quelsolaar :)
saghm 4y ago
> The best solution I have found, disregarding of language, is to use the same language to write a program that generates the code you need. Sounds like a pitch for lisp; I haven't really used any lisp variant much, but I always hear about people saying they basically write a program to generate their program rather than actually just solving the problem directly.
- LanternLight83 4y ago
  Absolutely; Complex macros are frequently written by breaking them up into smaller "actual" functions. The body of the macro just receives it's unevaluated arguments and calls those functions on them, because the only thing that's special about it is when it runs, that it's arguments are initially unevaluated, and that it's output is interpreted (possibly by a compiler) as code. Within the context of the macro's body, it's lisp like any other.
- kaba0 4y ago
  Or zig’s compile time functions.
jbboehr 4y ago
Procedural macros[0] in Rust seem to fit this a bit. Although you don't see the generated code unless you use something like cargo-expand[1]. [0]: https://doc.rust-lang.org/reference/procedural-macros.html https://doc.rust-lang.org/reference/procedural-macros.html [1]: https://github.com/dtolnay/cargo-expand https://github.com/dtolnay/cargo-expand

jesse__ 4y ago

I definitely agree. I'm actually in the middle of writing a C metaprogramming runtime (effectively a parser that spits out an AST) which is useful for writing such programs. Also, unrelated, but I miss watching your streams on Twitch, assuming you're the same quelsolaar :)

saghm 4y ago

> The best solution I have found, disregarding of language, is to use the same language to write a program that generates the code you need. Sounds like a pitch for lisp; I haven't really used any lisp variant much, but I always hear about people saying they basically write a program to generate their program rather than actually just solving the problem directly.

LanternLight83 4y ago
Absolutely; Complex macros are frequently written by breaking them up into smaller "actual" functions. The body of the macro just receives it's unevaluated arguments and calls those functions on them, because the only thing that's special about it is when it runs, that it's arguments are initially unevaluated, and that it's output is interpreted (possibly by a compiler) as code. Within the context of the macro's body, it's lisp like any other.
kaba0 4y ago
Or zig’s compile time functions.

jbboehr 4y ago

Procedural macros[0] in Rust seem to fit this a bit. Although you don't see the generated code unless you use something like cargo-expand[1]. [0]: https://doc.rust-lang.org/reference/procedural-macros.html https://doc.rust-lang.org/reference/procedural-macros.html [1]: https://github.com/dtolnay/cargo-expand https://github.com/dtolnay/cargo-expand