>>7,8 Wrong
1.void.h does not emulate any LISP/Scheme/Haskell, it just uses a handful of functional macros(mainly apply variants). the defvars/defuns is just to test code generation with arglist tuples, i never use them in real code.
2.there is no interpretation whatsoever, it runs at speed of C.
3.its not buggy by itself(its safer than plain C), it just hard to debug because of macro expansion and lack of recursion(no nesting in same macro)
4.Its less powerful than a lisp, but it can do most of what lisp can because of turing completeness. Most of lisp/haskell/etc is actually "abstract lego blocks" which is counter productive to performance. C allows to use zero-cost macro abstractions which have "fine tuned pieces":
i.e. its "coarse lego blocks" vs C "fine small parts".
The perceived inelegance of C is because of lots of "fine small parts" need to be carefully created and matched vs lisp composition of standard blocks for rapid prototyping. When you abstract out the C code into a macro, the "inelegance" disappears and there is no loss in flexibility or performance. Thats the stimulus for developing these headers. I don't really like lisp and the cult around it, they treat stupidly basic things like apply like some revelation from god(which doesn't exits btw) or "spirits within the computer", when in fact its just a shortcut to writing less code(and a really primitive one). "Satori" or the ability to write shit code rapidly is not appealing at all, lists and recursion are dead-end backwaters,
Paul Graham-tier drivel all about writing shitty code rapidly without regards to the hardware. Garbage collection (despite being claimed as faster) is never faster or more efficient and dynamic typing is useless(thankfully JS is now centered on real typed array) and harmful for performance.
All that hype about these high-level languages is just going to die eventually, their spot in the limelight is due fact writing correct C/C++ is hard and developers pick the easy way out.
Spoiler: eventually all the "easy way" frameworks/libraries will just be replicated in C/C++. It would take more coding time. But in the end, the "rapidly designed prototypes" will be replaced by much faster and less memory hungry "concrete static binaries".
>>3 why i don't switch to C++
Even though C++ dominates the industry, its actually inferior to C, the complexity and uselessness of most C++ abstractions force people to use the C parts and idiomatic C, the safety promise of C++ type checking and const correctness are actually really counter productive(its actually faster to replace const with #define and type templates with _Generic). C++ doesn't have any useful features that couldn't be done with use of macros and forced OOP/Template paradigm doesn't inspire much confidence in its performance.
So i decided void.h will never be ported to C++ or to different compilers than gcc. I would likely make different headers to work with C++ code, when i have the need to do it.Either use C or don't use void.h