Macros on Steroids: How pure C can benefit from metaprogramming • Hacker News Board

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#21

Post by Hirrolot » Thu, Jul 22, 2021, 5:48 PM UTC

IncRnd wrote: post #20

You could create this as a frontend macro preprocessor that implements new language constructs. Maybe it could be called cfront. I just hope that the usefulness of that doesn't lead to bloated and complex codebases and binaries as features are added to the preprocessor.

There are several reasons why not to resort to third-party code generators [1]. This includes the burden of maintenance (think about the build process) and seamless integration of native macros with other code.

Do you have some code to show bloated binaries with Datatype99/Interface99? The last time I checked the generated assembly code, it was nearly of the same size as hand-written code [2].

[1]: https://github.com/Hirrolot/metalang99#q-why-not-third-party... [2]: https://godbolt.org/z/ns6Ma7csd

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#22

Post by WalterBright » Thu, Jul 22, 2021, 5:52 PM UTC

d_tr wrote: post #11

WalterBright wrote: post #7

My not-so-humble opinion is that if you're using the C preprocessor to do metaprogramming, you have outgrown C and need a more powerful language.

I humbly agree unless, of course, there is no other solution, e.g. lack of compilers on your platform.

Even so, I used to do a lot of metaprogramming with the C preprocessor back in the day. Over time, I grew disillusioned with it and gradually removed it from my C code. It just wasn't worth it.

P.S. I also did metaprogramming in C by writing C programs to generate C code, such as converting an array of structs to multiple arrays, one for each field (for efficiency). This worked out fairly cleanly, but with D's ability to run functions at compile time, I was able to put this back into the main program.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#23

Post by Hirrolot » Thu, Jul 22, 2021, 5:55 PM UTC

jjnoakes wrote: post #19

Can anyone with some real experience with this comment on the debug visibility? In gdb or lldb or otherwise? How easy is it to see what is going on, partially expand macros, get at intermediate values, or evaluate things at the debug prompt? At first glance it seems like it'd be quite obfuscated but perhaps I will be pleasantly surprised by some experience reports.

If you're asking about debugging macros, I've put a huge effort to this [1]. There are several macros that help you test, debug, and report errors at compile-time. For example, you can make calls to ML99_abort and see the expansion with -E. Usually I debug macros in this way.

If you're asking about debugging code generated by macros, Interface99 has no problems with it since the generated code is trivial, pretty much as if you wrote by hand. Datatype99 can introduce a little inconvenience into it as it generates a single-step for-loop for each variable binding [2], but this should not be a big problem too.

[1]: https://hirrolot.gitbook.io/metalang99/testing-debugging-and... [2]: https://hirrolot.github.io/posts/compiling-algebraic-data-ty...

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#24

Post by lhorie » Thu, Jul 22, 2021, 5:57 PM UTC

Hirrolot wrote: post #14

lhorie wrote: post #8

Something about macros that I don't see discussed much is the trade-off between improved clarity of intent vs learning curve for contributors. I don't have a ton of experience w/ C, but the large projects I've seen appear to have a tendency to avoid heavy macro usage (e.g. using `void *` for hashmap implementations instead of reaching for macros, for example). I see macros appear more frequently among those that prio…

I'm currently using Datatype99 & Interface99 at work. What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code. Regarding macro-based eDSLs, I would not resort to them for needs other than abstractions to be considered as a part of the language (ADTs, interfaces, etc.), since they are like languages on their own; when you try to understand/contribute to eD…

That's interesting. The reason I'm asking is that I'm interested in the open source adoption angle. For example, say Linux went ham on DSLs, would people unwillingly learn it for the sake of being able to be part of the large community, would they embrace it as if it's the next best thing after sliced bread, or is that just never going to happen because of some strong conceptual aversion to the paradigm? Or say a not-so-known C projects wants to gain adoption/popularity, would the choice of using DSLs be a showstopping consideration?

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#25

Post by Zababa » Thu, Jul 22, 2021, 5:57 PM UTC

nicoburns wrote: post #5

gsmecher wrote: post #3

There are good reasons to reach for macro libraries. They're rare, but they're out there. I make heavy use of boost::preprocessor in a C project and it was fundamentally enabling. I have occasionally cursed at it but never regretted it. It is basically impossible to provide a "kind" development environment using deep macro trickery. The error messages you get from this kind of library are a major handicap. This faili…

If you need these kinds of advanced metaprogramming capabilities then I feel like that's a sign that maybe plain C isn't suitable for your project and you'd better off switching to Zig, Rust, D or C++. These all provide powerful compile-time execution capabilities and the ability to expose C interfaces.

If you want ADTs and can afford the (slight) performance hit and the higher resource consumption, you can even look into OCaml.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#26

Post by Hirrolot » Thu, Jul 22, 2021, 6:01 PM UTC

lhorie wrote: post #24

Hirrolot wrote: post #14

Earlier quoted context omitted.

I'm currently using Datatype99 & Interface99 at work. What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code. Regarding macro-based eDSLs, I would not resort to them for needs other than abstractions to be considered as a part of the language (ADTs, interfaces, etc.), since they are like languages on their own; when you try to understand/contribute to eD…

That's interesting. The reason I'm asking is that I'm interested in the open source adoption angle. For example, say Linux went ham on DSLs, would people unwillingly learn it for the sake of being able to be part of the large community, would they embrace it as if it's the next best thing after sliced bread, or is that just never going to happen because of some strong conceptual aversion to the paradigm? Or say a not…

I'd wager no, as long as you remain sane and do not pollute everything with fancy macro eDSLs. Specifically Datatype99 & Interface99 can be good for newcomers because they make code more concise, less intimidating and intricate.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#27

Post by wudangmonk » Thu, Jul 22, 2021, 6:18 PM UTC

WalterBright wrote: post #7

My not-so-humble opinion is that if you're using the C preprocessor to do metaprogramming, you have outgrown C and need a more powerful language.

I agree that you shouldn't use the preprocessor for metaprogramming, it sucks. Switching to C++ is not a solution either since its template system is garbage for metaprogramming aswell.

Starting small with a small utility such as this one or creating one of your own is the best aproach in my opinion.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#28

Post by Zababa » Thu, Jul 22, 2021, 6:40 PM UTC

lhorie wrote: post #24

Hirrolot wrote: post #14

Earlier quoted context omitted.

I'm currently using Datatype99 & Interface99 at work. What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code. Regarding macro-based eDSLs, I would not resort to them for needs other than abstractions to be considered as a part of the language (ADTs, interfaces, etc.), since they are like languages on their own; when you try to understand/contribute to eD…

That's interesting. The reason I'm asking is that I'm interested in the open source adoption angle. For example, say Linux went ham on DSLs, would people unwillingly learn it for the sake of being able to be part of the large community, would they embrace it as if it's the next best thing after sliced bread, or is that just never going to happen because of some strong conceptual aversion to the paradigm? Or say a not…

I'd say it can be the opposite. If the DSL is addressing a real and common problem in C codebase, it's better to use it and that everyone use it rather than have everyone create their own special DSL.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#29

Post by nomel » Thu, Jul 22, 2021, 6:48 PM UTC

lhorie wrote: post #8

Something about macros that I don't see discussed much is the trade-off between improved clarity of intent vs learning curve for contributors. I don't have a ton of experience w/ C, but the large projects I've seen appear to have a tendency to avoid heavy macro usage (e.g. using `void *` for hashmap implementations instead of reaching for macros, for example). I see macros appear more frequently among those that prio…

> vs learning curve for contributors

Early on in my programming career, I implemented all sorts of beautiful magic, but I was alone. Later, I realized that beautiful magic was keeping me alone. Now, much later in my career, I program mostly like a novice. I don't write clever code, I unroll powerful one liners into boring for loops, and I use all sorts of temporary variables to make intent perfectly clear, because I want and need as much help as I can get. Confusing contributors for some wanky obsession with "terseness" or "elegance" is a good indication of either a great team, or someone that works alone.

Re: Macros on Steroids: How pure C can benefit from metaprogramming

#30

Post by ska » Thu, Jul 22, 2021, 6:56 PM UTC

gsmecher wrote: post #3

There are good reasons to reach for macro libraries. They're rare, but they're out there. I make heavy use of boost::preprocessor in a C project and it was fundamentally enabling. I have occasionally cursed at it but never regretted it. It is basically impossible to provide a "kind" development environment using deep macro trickery. The error messages you get from this kind of library are a major handicap. This faili…

> It is basically impossible to provide a "kind" development environment using deep macro trickery.

Unless it's in a language actually designed for meta-programming. Obviously if you are already in a C project this might not be practical, but if you need a lot of it you may just be using the wrong tool for the job.